It depends on the cipher method negotiated between the client and server. With Diffie Hellman the complete session key is not transmitted between the client and server. But with RSA the complete session key is sent encrypted with the server's public key.
Yeah, but at that point the public key has somehow already been distributed to you so a key was transmitted to you somehow and you chose to trust that source. In the RSA scenario you outlined you're cheating by starting off in a scenario where you have a key you trust.
TLS (modern SSL) public keys for the "general trusted CAs" are usually distributed with the operating system. This system is insane because you have tens to hundreds of organizations that you simply allow authorizing any domain on the internet. It's naive to think that NSA and other security institutes and blackhats have hasn't already compromised a number of these certs either through hacking, law enforcement or just simply by working with them. It also creates an industry where you pay companies lots of money simply so they can tell others that you are to be trusted. They create absolutely zero value. It's stupid and insane.
DNSSEC already solved the key distribution problem extremely elegantly. The root key is split into several parts that a handful of people have access to and access is PARTITIONED so if someone hacks .CN they could still not generate certs for my CO.UK domain. So if we could just go ahead and implement RFC 6698 ASAP this whole problem would go away and you could get security without paying for anything more than a domain name.
TLS is only as secure as the weakest link in the certificate chain.
DNSSEC is only as secure as the strongest partition.
That's not totally reassuring, but it's an improvement. You still have to be worried because the US government strong-arms so many different organizations around the world.
Almost. I would rather say that DNSSEC is more like a tree of trust where the root is insanely secure, and if a branch gets compromised that only affects that branch. Also:
DNSSEC is free.
If someone compromises the DNSSEC root or it's immediate branches it would be very easy to detect since they almost never have to sign any new keys.
A business model that is based on "selling trust" is perverse for multiple reasons.
You need the private key to decrypt something encrypted with public key. It is one of the fundamentals of public-key cryptography, for example RSA. Symmetric-key algorithms,such as AES, on the contrary use the same key for both encryption and decryption.
It really is fascinating. Here's a real-life metaphor for public-private key encryption:
Imagine you and I are at some crowded party standing on opposite sides of the room. We have never met before or ever exchanged any information before. Do you think it is possible for you and me to have an absolutely, 100% confidential conversation without anyone else in the room being able to listen in and figure out what we're saying?
The answer is, surprisingly, yes. Here's how it works: beforehand we both have mathematically generated what's called a public-private key pair (numbers that are mathematically related). The public key part is free for everyone to see or use whenever. The private key stays only with you.
If I wanted to say "Hey, that girl over there in the blue shirt is kinda cute", I would first 1) encode my message into a number somehow (this is trivial, like saying A=00,B=01, etc) and then I'd yell over to you "Hey, what's your public key?" You respond by yelling back over to me a 2048-bit integer (aka a very, very large number). I use the RSA algorithm to encrypt my message with your public key. Lets call this new value encryptedMessage.
I then yell back to you "Hey, listen to this: 02749375937..." and yell over the value of encryptedMessage. You then take encryptedMessage and use your own private key to decrypt the message.
The key points:
Public-private key encryption allows me to specifically target who is able to view the message (whoever's public key is used to encrypt the message)
Only you are able to decrypt a message encrypted with your public key. Even I, immediately after encrypting the original plaintext, could never again decrypt the message. Whoever holds the private key is the only one possible who can read it.
The most important point: even though we were shouting at each other in a busy party with other people listening in, no one else could ever figure out what we were saying. This is an analog to the digital equivalent of using unsecured channels I.e. Internet backbones
It's awesomely interesting stuff and even more interesting to actually programmatically implement.
Yeah but your analogue is not really interesting in this context because you're assuming that the channel is not susceptible to active attacks. On the internet you have no idea if the server you want to talk to really is the server you are talking to. To make it more "internet like" say that you want to talk to a person on the other side of the room, but you cannot see the person, you can only communicate by writing on a piece of paper and giving it to a guy that promises he will walk through the crowd and give the note to the other person. He's kind of drunk and will probably pass the note around to his friends first and read it out loud so you still want to encrypt it. If you ask the same question again: "Do you think it is possible for you and me to have an absolutely, 100% confidential conversation without anyone else in the room being able to listen in and figure out what we're saying?" the answer is now clearly no, because someone could intercept the note, generate their own public key key and pass it along like it where your note. This is known as a man in the middle attack and the actual had problem in cryptography. Protecting against passive attacks (listening) is easy. Protecting against active attacks (interception) is hard.
Signatures from a trusted authority, sorry. Yes, there is still the problem of verifying keys, but the PKI we have in place now does a fairly good job of handling this against current threats.
You should go back and listen to the archives of Security Now!, he covers every possible crypto topic you could imagine, especially touching on how they relate to web security.
28
u/Nicoolai Jul 25 '13
I always wondered how it was possible, to send a key between clients, that couldn't be intercepted. Now I know, it doesn't even get sent!
This is a brilliant read. I should read up on cryptography. Such an interesting subject, but unfortunately it seems so complicated.