9

I apologize in advance if I am fundamentally misunderstanding something, but is it possible to have encrypted communication protocols (https, I suppose) without resorting to a certificate system?

This questions comes regarding the EFF/Mozilla initiative to "encrypt everywhere!" I understand that certificates verify /identity/ but is it possible and/or reasonable to build a https protocal witbout using verified identities? The most obviosyu example is communicating with self-signed cert sites, but are there other situations where you might value the encryption of the communication more that the identity of who you are communicating woth?

sharedphysics
  • 103
  • 1
  • 1
  • 4

5 Answers5

8

You can have SSL/TLS without certificates. This is supported in the TLS standard: the "DH_anon" cipher suites involve no certificate whatsoever. But you have to remember that such an unauthenticated TLS is inherently weak against active attackers, since they cannot prevent client or server impersonation (or both at the same time, which is called a Man-in-the-Middle attack).

Most Web browsers deactivate DH_anon cipher suites because of the inherent vulnerability to MitM. You can have the same conceptual effect with a self-signed SSL certificate, that you can produce yourself without talking to any CA. Of course, the same Web browsers will then show the "scary warnings", for pretty much the same reason.


From the EFF point of view, whose arch-enemy is the NSA, generalized DH_anon cipher suites would make sense, since Evil Spy Agencies™ are know to prefer passive eavesdropping (since it leaves no incriminating traces). Passive eavesdropping is defeated by DH_anon. However, for most other people, the biggest threat is not governmental intrusiveness, but mundane con-artists that try to separate you from your money, and these do not hesitate to run full MitM attacks, e.g. with fake WiFi access points.

The Let's Encrypt initiative aims at making certificate issuance free (as in "no money") and automated, while still maintaining a bit of effort at "verifying" that whoever obtains the certificate has some degree of control over the designated domain. From the look of it (it deserves closer inspection), this system relies on the DNS and implies that any DNS attack (e.g. DNS spoofing) might be leveraged into rogue certificate issuance, in a fully automated way, so this initiative would be a weakening of the current certificate model. On the other hand, if it convinces more people to use SSL, it contributes to a "safer World", at least from NSA-is-the-Devil point of view, where what matters is defeating passive eavesdroppers.

Anyway, without support from Microsoft and Google (i.e. inclusion of the Let's Encrypt root CA in IE and Chrome), there is no way that the initiative really turns into generalized HTTPS. Not a lot of people would activate SSL on their Web site if it means that 70% of users will get insulted and scared away by their browsers. If Microsoft and Google don't jump in the wagon (and I don't believe they will), then the Let's Encrypt system will remain a political gesture, but won't be widespread (and ultimately Mozilla will drop it if someone bothers to mount an automated DNS-based attack).


There is another completely different certificate-less mode for SSL; it is called SRP. That one is safe, but different from normal Web browsing. SRP ensures mutual client/server authentication with regards to a shared secret, and it does so in a way that protects the shared secret against offline brute force -- so it can tolerate the use of a low entropy shared secret, i.e. a password. TLS-SRP makes a lot of sense for accessing password-protected network resources, and it involves no certificate at all; and yet, it is safe against MitM and eavesdropping.

Unfortunately, Web browsers don't currently support SRP.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • I've done the closer inspection, and I've found [this paragraph](https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.txt#L981), explaining that DNS is only used the first time, and after a certain key has been trusted, that is used instead for verification. Also, lets encrypt is also supported by the CA "IdenTrust". AFAIK, unless there is some conflicting policy issue, they can issue an [intermediate CA key](https://en.wikipedia.org/wiki/Intermediate_certificate_authorities) for let's encrypt, as at least their "commercial root CA" has a pathLenConstraint of 1. – user10008 Nov 20 '14 at 18:09
  • StartSSL for example also uses DNS in a fully automated way. They either send you a mail to postmaster@domain.com, or to the mail address from the DNS entry. – user10008 Nov 23 '14 at 22:39
  • It is not _fully_ automated -- otherwise you would get your certificate right away, not several hours or days later on. A human being is still involved, even if you don't get to talk to that person. – Tom Leek Nov 24 '14 at 13:02
  • Ok didn't know that. Then it really seems to be a weakening. – user10008 Nov 24 '14 at 16:19
6

SSL/TLS (the underlying protocol for HTTPS) provides two features:

  • Encryption, so that nobody could passively listen to the data. Encryption is done using a key which is somehow shared between the peers.
  • Identification, so that you can be sure who you are talking to. This is usually done with certificates.

While you might have encryption without identification your connection would be open to active attacks, where instead of the expected peer you talk to another party, like a man in the middle which then can decrypt and manipulate the data and forward the data to the original peer after re-encryption.

Without identification does not mean only without certificates but also when you trust just any certificate you get, typically self-signed certificates.

Thus, while TLS itself could do encryption without certificates, HTTPS requires certificates because this is the only way for proper identification in this use case.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 1
    The paragraph about encryption without identification isn't very clear. The key idea is that in the presence of an active MITM, there *cannot* be encryption without identification. – Gilles 'SO- stop being evil' Nov 20 '14 at 13:53
  • @Gilles: I don't really understand your comment. There can be encryption without proper identification, but then you might communicate with the wrong peer (MITM). If you want to be sure to communicate with the right peer you have to use proper identification of the peer. – Steffen Ullrich Nov 20 '14 at 14:10
  • 1
    Yes, sorry, I meant there cannot be *confidentiality* without identification. There can be encryption, but if you can't know who has the key to decrypt, encryption doesn't give you confidentiality. – Gilles 'SO- stop being evil' Nov 20 '14 at 14:23
1

The data over https connection is encrypted using a private key, which is known to both sender and receiver. The sender encrypts the data using the private key and the receiver uses the same key to decrypt the data.

The same key is not reused again to prevent the replay attacks. Therefore, a unique key must be used in every session.

Now, the question is who generates the unique key and how do we share this unique key in every session. This is a problem, right? This unique private key is shared using a public-key infrastructure and certificate is integral part to it. Generally, the request is initiated by the client (in this case the browser). The certificate includes the information about server's public key which is used to encrypt a random private key generated by the client. This data can only be decrypted by the server's private key which is known only to the server. Once the private key is established between the client and server, they can start communicating securely, which is essentially the https.

Curious
  • 1,442
  • 2
  • 14
  • 26
  • 2
    with Diffie-Hellmann Key Exchange no certificate is needed to exchange the key. The certificate is only used for identification. – Steffen Ullrich Nov 20 '14 at 05:39
  • yes but neither can it prevent Man in the Middle Attack. Using public key to encrypt the data guarantees that the symmetric key is shared only with the server. – Curious Nov 20 '14 at 05:47
  • 2
    With DHE no clear text keys are send, even if no certificates are involved. But the servers signs what it sends to prove that it has the private key. – Steffen Ullrich Nov 20 '14 at 06:17
0

No, you can't have HTTPS without use of SSL Certificate/public key.

With SSL Certificate the server identifies itself to client.

If you having Self-Signed Certificate you'll have HTTPS, but self-signed certificate is not trusted by modern browsers.

  • This answer could be improved by explaining why a self-signed certificate isn't trusted: It protects against an eavesdropper, but a man-in-the-middle who can change the data which is transmitted can intercept the self-signed certificate and replace it with their own. – Philipp Nov 20 '14 at 08:06
0

Regarding alternatives to certificate based (asymmetric) encryption for communication protocols, symmetric encryption is a possibility such as a shared key known by both parties.

Considering alternatives to SSL and in particular certificates, consider encrypting the data before it is placed on the wire. This would allow you to use any number of protocols as the transport while ensuring the data cannot be viewed. Successful decryption would then signify the data successfully arrived at its destination and wasn't tampered with.

Technically you can't have https without SSL due to the URI scheme. This wikipedia article does a great job explaining this and includes links to RFC articles if you're looking for something more technical. In short, the specification states that the https scheme corresponds with SSL/TLS. Note that this excludes scenarios where one forgoes RFC specifications in favor of their own solution (example: roll your own encryption) where you would create your own specification for https. Anyone consuming that service would then need to understand the custom specification.

user2320464
  • 1,802
  • 1
  • 15
  • 18