|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Jason Brvenik (jason
brvenik.com)Date: Mon Jan 07 2002 - 11:15:20 CST
The short answer is no.
The long answer goes like this ( simplified )
In my previous message I mentioned 6 basic steps they were:
1) Client connects and requests the ssl session
2) Client inspects provided credentials for validitity.
3) Allow / Deny based on trust that is explicit or granted.
4) A symetric key is negotiated and exchanged using the public/private keypair of the server certificate.
5) all communication is done with the symetric keys.
6) some time later ( or after a qualifying event ) the keys are renegotiated.
It is step 4 we are most interested in with this question. Looking a little further into PKI and assuming that the certificate is not compromised ( there are few other more crypto techie babble things in this assumption as well like key length, key generation, cipher usage, randomness... )
The whole process relies on the concept of public key cryptography which in short means that for every encryption key there is a seperate corresponding decryption key.
This means that
1) something encrypted with a public key can only be decrypted with the corresponding private key.
2) something encrypted with a private key can only be decrypted with the corresponding public key.
Step 4 looks like this from a 50,000 mile view.
4a) Client negotiates a cipher that will be used with the server.
4b) Client generates a key for use with the server.
4c) Client encrypts the key using the servers Public key presented in step 2 above.
Remember: "Something encrypted with a public key can only be decrypted with the corresponding private key."
4d) Server decrypts the encrypted key with it's private key.
4e) SSL begins.
Since the symetric key is only known to the client and the server ( via the servers private key ) the information cannot be decrypted without mounting a brute force attack to discover the servers private key. There are usually easier ways to gain access to the information in question than trying to break the encryption like social engineering and key theft.
Hope this makes it a little more clear.
Jason.
[ Andrew ] wrote:
> One thing I've never had properly explained to me:
>
> If a hacker was sitting in a web cafe sniffing all the traffic, and captured
> the entire stream of data from the person connecting to the OWA server,
> couldn't they just replay the information to decrypt the data arriving at
> the client? I've been told no, but I haven't found anything/anyone that
> explains why not.
>
> Surely to negotiate a method of encryption that the client can decrypt,
> information must be passed between the systems that the wiley h
x0r d00d can
> use to decrypt or replay the session...(?)
>
> Cheers
> Andrew
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]