Question on HTTPS

[Udgnim]

let's say there is a user purchasing something on a website that has a valid SSL certificate

I understand that the user's computer will use the website's public key to encrypt and send to the website which will then decrypt the user's data with the website's private key

the thing I'm wondering about is when a website encrypts data with its private key to send back to the user. the user's computer will decrypt with the website's public key.

doesn't this actually represent a security risk because anyone that intercepts the website's transmission to the user can decrypt the data with the website's public key?

another question, if a website has an invalid SSL certificiate (let's say the website name doesn't match what is stated on the cert), does a HTTPS connection still take place if the user tells the browser to proceed?

thanks for the help

 

[unokitty]

Udgnim,

You are correct that anything that is encrypted with a server's private key will be unencrypted with the related public key. This provides authentication and non repudiation. However, as you have observed, it does not provide confidentiality.

That said, most information sent between a server and a client will be encrypted with a one time use session key rather than with an asymmetric private key.

If you have the time, you can find more information about cryptology at:

http://www.cryptool.org/

If a website has an invalid SSL certificate, the client (user) will receive an error message. The exact error message will depend on the particular browser. Should the user tell the browser to connect anyway, then it will.

This is the mechanism that is exploited in the SSL man in the middle attack. For more information, see:
http://en.wikipedia.org/wiki/Man-in-the-middle_attack

All the best,
Uno

 

[LiuKangBakinPie]

TLS/SSL, traffic can be recognized as being TLS/SSL easily, and an observer could see the certificate exchange
The most helpful aspect of SSL is that the chain-of-trust principle removes the need of knowing each other and exchanging keys securely. It is also its biggest weakness.
If your talking about sophisticated man in the middle attacks then unfortunately no.

If your worried about security use this everytime you connect to the secure sites
www.your-freedom.net
You can use the free part which would be enough for the occasional private transactions.

Currently used algorithm (client versions 20110510-01 and above) does not use the password, but an MD5 hash of the concatenation of the username and the password. Everything else is the same. Since the password is no longer part of the encryption key (see below), the server no longer has a "need to know", it only knows the MD5 hash. In the authentication response, the client also sends a 256bit random secret -- this secret is encrypted with a 2048bit RSA public key. Only the servers can decrypt it. We intend to change the key pair frequently (so update your client installation from time to time!)

 

[Ghiedo27]

The thing I'm wondering about is when a website encrypts data with its private key to send back to the user. the user's computer will decrypt with the website's public key.

I think it's worth noting that the website does NOT use its private key to encrypt anything. Its sole purpose is to decrypt the authentication response from the remote host. Keep in mind the remote host is using the server's public key to hash the first response (authentication):

In the authentication response, the client also sends a 256bit random secret with a 2048bit RSA public key

At that point the server is going to use that 256bit random secret from the remote host for AES encryption. Both the server and host know this number and can use it for symmetric encryption. You could never use the asymmetric public key to decrypt the AES encrypted data. Each host will generate its own 256bit random secret with the public key so every session with the server will be encrypted differently.