Https

Hello everyone,

I am a website designer but am trying hard to increase my awareness and knowledge of internet security related issues.

I wonder if you guys could help me first with a really simple question:

my understanding of HTTPS is that it is not enormously secure. If I understand its workings correctly, a private key is agreed on in plain text transmission before encrypted messages begin, meaning that if someone is snooping on packets between the client and the server, they can utilise this private key to crack the following encrypted messages. Is this incorrect? Have I completely misunderstood this?

Many thanks! :-)

Yes, you have completely misunderstood this!

If you take a minute to think about it, the motivation for SSL/TLS (TLS is the more up-to-date standard) is that internet connections can be snooped by eavesdroppers, this is why encryption is used. If keys were exchanged in the clear, there would be no security benefit at all!

There are ways to set up session keys that are designed not only to protect against eavesdropping (snooping), but also against an adversary intercepting AND REPLACING packets, so as to impersonate each side to the other (this is called a man-in-the-middle or MITM attack). SSL/TLS uses such protocols.

You can start your education here:

http://en.wikipedia.org/wiki/Secure_Sockets_Layer

So, SSL/TLS doesn't make the elementary blunder you were concerned about. But the security it provides is debatable, and debated. Maybe the biggest weakness is that certificates (used to authenticate the identity of servers) aren't managed carefully enough, lots of legit websites use bad certificates, and users often ignore the browser warning that there is problem with the certificate. Because of these problems, if Badguy Inc. sets up a server on a domain that looks like goodguys.com, there's a good chance that people will get fooled. Sigh.

Maybe the worst mistake so far happened (only a couple of years ago) in Debian Linux distributions: some f**kwit altered crypto code he didn't understand (because his super-duper-lint program complained), and made key generation completely insecure. If such keys were used for signing certificates, forgery became easy. Sigh.

As far as I know, SSL/TLS is a well-designed system. But the defense is only as strong as its weakest point...

Thanks so much for your reply and taking the time to educate me.

I understand about the MITM attacks, I just haven't quite got my head around how two computers can talk to each other in code, if they haven't already in plain text discussed what code they are going to encrypt their later communications in. How does this actually work?

I mean, I have read the SLS/TLS wiki page and understand what is says about the handshake... "The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite....... and PreMasterSecret". Surely if the random number and the PreMasterSecret is transmitted in plain text, a hacker who listens to the communications of the client can comprehend later communications between the client and the server?

Is my misunderstanding being stubborn, I apologise!

Thanks for the explanation of the context regarding the certificates... you talked about 'dodgy' certificates, right? Is this why FF3 attempts to contact the original CA to check whether the certificate is kosher?

Public-key cryptography makes possible various seemingly impossible things. It was my curiosity about "how the hell do they do that?" that prompted me to pick up a crypto textbook around 2002.

Here's a couple of highly oversimplified answers, that I hope may inspire you to learn more.

[1] With a public-key cryptosystem (RSA being the most famous, and also very widely used), I can publish my key in a newspaper, on a web page, etc. Anyone can use this key to encrypt a message that only I can decrypt.

So suppose that you and I want to start a conversation secure from eavesdropping: I could begin by sending you my public key. You can then generate a random session key (for a block cipher like AES), encrypt it using my public key, and send that to me. We now share the session key, but the eavesdropper doesn't know it: he only has an encrypted version that he can't decrypt.

[1a] In the above scenario, if I'm impersonating the person you thought you were talking to, we have a "secure" connection, but your data is going to the wrong guy!

It is because of such scenarios, that certificates are required. Certificates are designed to be unforgeable. When I start the conversation, I send you my certificate. The cert probably already has the key you will use to encrypt the session key: if it doesn't, I sign the key I'm sending you, and you will verify that it's my signature using the signature verification key in my cert.

Keep in mind that this is highly oversimplified, but the proper use of certificates will defeat impersonation attacks including MITM.

[2] Diffie and Hellman (authors of the very first published paper on public key crypto) came up with a different way, that is crushing in its simplicity. Using an agreed number (that can be completely public), I raise this number (call it g) to a randomly chosen exponent, which we'll call a, and send it to you. You'll choose your own random exponent b, raise the base to this power, and send it to me. Each of us takes the number we received, and raise it to our secret exponent. So you compute (g**a)**b, and I compute (g**b)**a. Either way, it's the same as g**(a*b), so we have computed the same number, which we can use as our session key.

The eavesdropper has both g**a and g**b, but there is no practical way for him to compute g**(a*b). How cool is that?

NOTE 1: For Diffie-Hellman to be secure, the exponents have to be enormous (many hundreds of decimal digits). It's only possible to compute such enormous powers within a finite mathematical group (finite, but huge). The group must be chosen so that the logarithm problem (the inverse of exponentiation) is too expensive to compute; otherwise, the attacker can take the logarithm of g**a to find a, and then re-create the session key. I didn't know anything about finite groups when I started studying crypto, but my textbooks and self-study helped me to learn, and to me this stuff is fascinating.

NOTE 2: The Diffie-Hellman key-exchange protocol (described above) is pretty obviously vulnerable to MITM attacks, so it must be "beefed up" with certificates and more message exchanges to be secure.

Goodness, that is absolutely amazing - indeed, I am inspired!

That really is just fascinating and I will pursue this further.

Thanks again for your energy and effort.

Truly grateful.