For anyone looking at packet tracing at the EAP-TLS level etc, I?ve done an audiocast on Keith Parson?s Wirelesslanprofessionals.com website. It may help beginners to understand some of the terminology used in SSL [ the ?father? of TLS and "grandaddy" of EAP-TLS ].
The good thing is that it has a ?pause? button, so if it?s about to put you to sleep, you can just put it on pause.
SSL is a massively ?long? subject. My original audiocast lasted two hours and I still missed stuff out. It?s not meant to be ?all encompassing?, but rather to act as a primer for further study.
Wow, good stuff Dave. Gonna listen to that. I am particularly interested in how to 'read' at the packet level what's going on with TLS. I know its encrypted but there must be something more you can get out of it. Thanks!
Fantastic podcast. I really enjoyed it. I do have a question though, specifically about the client phase. In the podcast you say that the client encrypts the PMSK with its private key and then re-encrypts it with the server's public key. My understanding of public key encryption was that the public key couldn't decrypt, just encrypt data. I was of the understanding that this was the strength of it, you could theoretically give your public key to anyone because that key couldn't be used to decrypt anything being sent to you, only encrypt. Yet you say in the podcast that the server uses the client's public key to decrypt the PMSK. I admit my understanding is taken from learning about how PGP works and not specifically SSL, but can you explain what is different about SSL that the client's public key is able to be used to decrypt the PMSK?
Good work and thank you sir.
@wilddev: Private key and Public key play a same role, we can use Private key to Encrypt and Public key to decrypt and vice versa,
Many thanks guys.
Chris, one of the nice things about public key/private key systems is that either the public key or the private key may be used for encryption.
Unfortunately this is not explained properly in many texts. They mostly just blurt out ?We always encrypt with public and decrypt with private?.
That is wrong. It depends on what you are trying to do.
This "encryption' is used for two different purposes normally. One purpose for "Data Confidentiality" and another for "If I can do X, you must be Y".
I'll explain a bit more about these now:
The first purpose is for true encryption. In documentation you will sometimes see this referred to as ?Encryption for Confidentiality. If I take a message [ we'll call it "X" ] and decide to encrypt it with a public key, to produce X [ ENCODED ], then only someone with a matching private key will be able to decode X [ ENCODED ].
The second purpose is for authentication. This is sometimes referred to as ?Encryption for authentication?. If I now take message X and encrypt it with my private key, anybody with a matching public key will be able to decrypt it. Because public and private keys are mathematically linked together and are generated together, if you are able to decrypt a message with a public key, then it MUST have been encrypted with the private key that corresponds to it [ in other words the other party ]. This is where authentication takes place. ?Now?, you say.?Hang on a minute. If I now have a message which has been encrypted with a private key, that means that not only can the person whom I want it to go to be able to decrypt it with my public key, but so can anyone else who has one of those public keys [ Public keys are often placed on websites for free use ]. So how do we get around it ? Let?s say we have Party A and Party B. There are some other security issues I won?t go into here, but it should give the gist of it.
A has his own private key [ A PRIV ] and has given a copy of his public key to B [ A PUB ].
B has his own private key [ B PRIV ] and has given a copy of his public key to A [ B PUB ].
I won?t get into how they exchange the keys here, as that would be a separate post, but we?ll just say ?via a secure method ? it could literally be A and B meeting in a caf? and A and B whispering in each other?s ears ? it has been done before ? nowadays we have electronic methods to do this ].
A takes message X and encrypts it with A PRIV. If A just sent this message to B, B could decrypt it, but so could anyone else who happened to be listening and has A PUB [ which could have been put on a website by A ]. To prevent this, A now takes B?s public key [ which could be available to anyone ] and encrypts [ ?message X encrypted with A PRIV ? ] with B PUB.
Now the ONLY [ provided that B has truly kept his private key ?private ] person who can decrypt that message is B with their B PRIV key. Once they have done that, they can then decrypt the ?message X encrypted with A PRIV ? using A PUB. If they can do this, then they know the message was encrypted with A?s private key [ A PRIV ].
We ?wrap? one thing in another.
So if this all so great, why do we even bother with symmetric keys ? One reason is that symmetric key encryption is much much faster than public key encryption. We can transfer symmetric keys via a public/private key method [ short and quick ] and then use the more efficient symmetric key encryption to encrypt actual user data. The advantage of public/private is that each end only needs to distribute the relevant public keys. It?s a very clever system.
There are systems to transfer keys securely over a public network [ like the Internet ] securely without these methods, but would be another audiocast.
Great post, I actually understood that, first explanation about private keys that I have got,
Another lightbulb moment, thanks dave1234
I had an aha moment too with that. So basically when they talk about the public/private key pair being one way, it means one of those pair of keys can decrypt an encryption made with the other one of the pair. The reason for not giving out your private key, then, is that if you keep one of the pair secret, then you can use the wrap method with anyone else doing the same thing to ensure the message is sent to the party its meant for, i.e. authentication, but the encryption part is that you are using one of the pair to encrypt the message. I can see why you said the same encryption can be used for two different purposes now.
Thanks for the clarification Dave. Its funny how you sometimes learn a complicated subject like this wrong due to how everyone else has also got it wrong, lol.
Yes, Chris. If you can remember:
"Encryption for Confidentiality"
"Encryption for Authentication"
you won't go far wrong.
Sometime in the future I'll go into how Diffie-Hellman works and how the IKE [ Internet Key Exchange ] works. The vast majority of texts cover IKE in one or two pages, and miss out a lot of key factors. It really needs at least a chapter to get a TRUE feeling for how it works.
The situation with security is similar to that of RF [ in general ]. In general, the texts out there are either pretty basic [ leaving out a lot of important information ] or way too complex [ in terms of what we need for day to day work ]. Not many ?fill in the middle gap?.
I am not sure how you could do this but do you think you could post a paper regarding this as obviously what you have said is the short version, even though itsa great help it may be a good idea if you could document it into one location for us, I know its work but we would be very grateful.
The issue is that you cant post docs into the forum?
Maybe CWNP would host it as a white paper.