What makes SSL secure?

 

I've been reading a few sites on the internet on how SSL works, but I don't understand how exactly it makes things secure. Probably because I don't understand completely how it works.

Let me begin with the core idea of SSL. It is used to encrypt HTTP connections, but for the client and the server to communicate with encrypted data, surely an encryption key needs to be shared. If someone is eavesdropping on your connection, wouldn't they just be able to grab this key and continue listening while decrypting the data? I can image this technique would work if we're talking about a long term connection, but HTTP requests are often completed within half a second.

Let's assume this is somehow taken care of. The other utilisation of SSL is to verify if a server is exactly who it says it is. What prevents a rogue server from faking a certificate signed by a root certificate provider? In none of the descriptions I've read, the browser actually contacted one of these authorities to verify the certificate with them. Let's assume the certificate is encrypted with a private key by the root certificate authority, how is the browser able to verify the data in this certificate without knowing the decryption key? Or is the decryption key different from the encryption key?

One solution to these problems I can imagine is if the certificate and key are only sent once and are stored along with the domain and IP address in your browser.

Thanks for explaining in advance.

First, some basic concepts about public key cryptography:

  • This relies on a pair of keys. One is the public key (which can be distributed); the other one is the private key, intended to be kept private.
  • You can encrypt data using the public key, which the private key can decrypt/decipher.
  • You can sign data using the private key, and this signature can be verified using the public key.

    • To make sure you're communicating with the right entity, you need to bind an identity to a key-pair. This is where certificates come in. A public key certificate is a signed document containing both the subject's identity (name) and the subject's public key. For example, the certificate for www.google.com contains its public key and the name www.google.com . It has been signed using the private key of a Certification Authority (in this case, Thawte). In the X.509 terminology (the common standard for certificates used for HTTPS), the CA is the issuer of the certificate, and it puts its name in the certificate too, alongside the subject's name, the subject's public key (and other attributes). The issuers are meant to verify the identity of who they issue a certificate for.

    The reason you don't necessarily see your browser fetching information from the CAs is that a number of commercial (or governmental) CA certificates are bundled with your browser or your OS. You trust them by default. This can be considered as a "leap of faith", but any trust mechanism needs this sort of starting point.

    You may want to read more about the TLS handshake, but in short:

  • The client gets the server's public key by looking into its certificate.
  • The client encrypts a secret using this public key and sends it to the server. The details of this depend on the cipher suite (could be Diffie-Hellman based), but the result of this should be a list of shared encryption keys (using symmetric cryptography, not public key cryptography).
  • These shared keys are only known to the client and the server, and they're used for encryption/decryption.

    • For SSL/TLS to be secure, you need at least 3 points:

  • A suitable cipher suite, and a successful handshake.
  • Verifying that the client trust the server certificate (typically, via a known CA in the PKI model).
  • Verifying that the certificate belongs to the server the client intended to contact (hostname verification).

    • (This is the case for the vast majority of usages of SSL/TLS (in particular HTTPS), but it's also possible to use other mechanisms than X.509 certificates with TLS, for example OpenPGP certificate or Kerberos cipher suites. This is less common as far as I know.)

    In order to encrypt a connection you have to agree to some shared secret. This can be done with diffie-hellman. To prevent man in the middle attacks, so you also need a certificate mechanism.

    For encrypting or signing (certificates) you can use asynchronous keys. This means you have two different keys (public and private key) to encrypt/decrypt. Usually you encrypt your data with a public key, and someone can decrypt it with his private key. Signing is done with your private key, and someone else can check it with a public key.

    So you see, faking a certificate is not that easy, since you don't have the private key from a root certificate provider.

    surely an encryption key needs to be shared. If someone is eavesdropping on your connection, wouldn't they just be able to grab this key

    No. The key is never transmitted. It is computed at both ends independently via a key-agreement algorithm.

    What prevents a rogue server from faking a certificate signed by a root certificate provider?

    The certificate is sent along with its digital signature which is made with the private key, and verified by the peer via the certificate's own public key. The server would need the private key of the server it is spoofing.

    链接地址: http://www.djcxy.com/p/21790.html

    上一篇: SSL客户端服务器通信

    下一篇: 什么使SSL安全？