• 0 Posts
  • 6 Comments
Joined 1 year ago
cake
Cake day: August 11th, 2023

help-circle

  • Be aware, that trusted Certificate Authority (CA) configuration applies to ALL certificates issued by CA. Thus, if one elects to trust “actalis” CA, then they trust ALL actalis CA users.

    If the process of obtaining certificate was extremely simple, easy and did not involve identity verification steps, then bad actors can take advantage of this process and create identities that your client application will trust.

    By itself the bad actor identity is of little concern to anybody, but it can have a significant impact if trusted identity is used in spam filtering, exploits of email client bugs or other hack attempts. Trusted users may be given higher access privilege at the client application level, which may be just enough for hacker to gain required access. For example, client application may be configured to trust all trusted senders with MIME attachments. An unknown trusted user sends malicious Application as file attachment. Accidental double click lunches the application, because sender is trusted. Congratulations, machine is pwned.


  • What I take issue with actalis, is that they don’t just sign your private key but you actually get the private key from them. It then depends on how much you trust the issuer.

    By definition, that key can no longer be considered “private”.

    It is very important to emphasize that the key in this model is not “private” anymore. Thus, all the communication using this key is not secure anymore.

    Private key is the one generated by hardware owned by the user and immediately secured with strong password. Ideally, private key does not leave the hardware that generated it. Thus, every device shall have its own private key.

    In less restricted model, private key gets copied by the user to other hardware using media like USB stick or P2P communication model that does not use cloud services.


  • Yes, it exists.

    But the receiving side needs to have its own certificate or to be more correct a private key represented by the certificate.

    Most people don’t know or don’t bother to obtain one.

    Same problem if PGP is considered.

    Cert based solution is supported by many clients, so it is easier on end user than PGP. But PGP is easier to manage for free. So there are some trade offs on both sides.

    The technology is very old for both cases. It has not caught on due to friction of key management (PGP private key or certificate in case of S/MIME).

    It is perfect if you want to communicate with family or friends as you can ensure everyone in your circle has their own private key. Even then I guarantee you will experience some friction to get this through.

    Organizations can have it easier as they can issue certificates to their users. But then problem of trusted certificate authority comes into play, if they use their authority. If they use well known authority, they have to pay.

    So, you can see how there’s friction in the solution. IMO, It is a good solution.



  • Signal runs a service. Even if its source code is open source there’s no guarantee that that’s the code running on the server.

    I don’t know the protocol, but I am concerned of man in the middle and how safe it is from man in the middle. In this case signal servers must be considered to be man in the middle.

    The only system to trust is peer to peer with proven track record of sending encrypted data over public channels.

    That’s PGP and Delta Chat utilizing PGP.