From: pk on 12 Dec 2009 08:52 My question is (apparently) simple, but I can't find a definitve answer. A SSL certificate, essentially, contains a public key bound to a subject, and the public key is signed by a CA. So clients receiving the certificate, that also recognize the CA, can validate the certificate. So far so good. But let's use the SSL certificate in a real scenario, like for example an HTTPS transaction. Is the server's public key contained in the certificate actually used in the SSL/TLS process (for signing or encrypting)? Or it's only the ciphersuite that client and server negotiate that matters, and the certificate is used only for server authentication? The underlying doubt is in fact: if the public key contained in the certificate is generated using some esoteric algorithm like elliptic curves, could that affect the SSL/TLS negotiations where the certificate is used if the clients do not support EC algorithms? Thank you in advance.
From: Will Dickson on 12 Dec 2009 11:38 On Sat, 12 Dec 2009 13:52:03 +0000, pk wrote: > My question is (apparently) simple, but I can't find a definitve answer. > > A SSL certificate, essentially, contains a public key bound to a > subject, and the public key is signed by a CA. So clients receiving the > certificate, that also recognize the CA, can validate the certificate. > So far so good. Correct. > > But let's use the SSL certificate in a real scenario, like for example > an HTTPS transaction. Is the server's public key contained in the > certificate actually used in the SSL/TLS process (for signing or > encrypting)? Yes. Exactly how depends on various details, but the public key in the server cert is used by the client to determine whether or not the server is who it claims to be (to some level of assurance). Or it's only the ciphersuite that client and server > negotiate that matters, and the certificate is used only for server > authentication? The ciphersuite that the client and server negotiate is used to encrypt and authenticate the data passing between the client and server; "authenticate" in this sense means verifying that the data has not been modified in transit. This is a separate process; in theory, a client could negotiate a ciphersuite with a completely unauthenticated server and perform the authentication by some other means (eg. as part of the application-level protocol). I'm not sure whether TLS allows this explicitly, although a client achieves the same effect by accepting a self-signed server certificate. (A client may choose to accept any certificate, even if it knows that the certificate is forged; in fact, most web browsers provide this option.) > > The underlying doubt is in fact: if the public key contained in the > certificate is generated using some esoteric algorithm like elliptic > curves, could that affect the SSL/TLS negotiations where the certificate > is used if the clients do not support EC algorithms? In this case, the client is unable to authenticate the server, since it can't verify the certificate signature. That doesn't necessarily prevent the client from accepting the certificate regardless and proceeding with ciphersuite negotiation, as described above. HTH Will.
From: Anne & Lynn Wheeler on 12 Dec 2009 15:21 pk <pk(a)pk.invalid> writes: > My question is (apparently) simple, but I can't find a definitve answer. > > A SSL certificate, essentially, contains a public key bound to a subject, > and the public key is signed by a CA. So clients receiving the certificate, > that also recognize the CA, can validate the certificate. So far so good. > > But let's use the SSL certificate in a real scenario, like for example an > HTTPS transaction. Is the server's public key contained in the certificate > actually used in the SSL/TLS process (for signing or encrypting)? Or it's > only the ciphersuite that client and server negotiate that matters, and the > certificate is used only for server authentication? we had been called in to consult with small client/server startup that wanted to do payment transactions on their server ... the startup had also invented this technology called "SSL" they wanted to use. the result of that effort is now frequently referred to as "electronic commerce". as part of that effort we had to do walk thrus of the business processes of these new things calling themselves Certification Authorities .... which issued these things called "digital certificates" (that were representation of their certification process). also part of that was assumptions about security of various parts of the process. initial assumption was that enduser knew the relationship between the webserver they wanted to talk to and the corresponding URL and the browser would use SSL to show the correspondance between the URL and the webserver being talked to; the combination would provide assurance between the webserver that the user thot they were talking to and the webserver that they were actually talking to. the original assumption were almost immediately invalidate when the merchants found that using SSL cut their thruput by 90-95% ... and dropped back to using SSL just for checkout/pay. now the user clicks on a button provided by (usually unauthenticated website) that supplies the URL. The result is that SSL is now just the part showing that whatever webserver being talked to is the webserver that it claims to be (potentially totally unrelated to the webserver that the user thinks they are talking to). SSL had two parts ... the authentication part ... and key-exchange part. With the authentication part falling back to just checking that whoever the webserver claims to be is the webserver it is ... then the primary use of SSL in the world today is (encryption) hiding account numbers and transaction details (for this electronic commerce stuff) while it is being transmitted thru the internet (between two endpoints). misc. past posts mentioning SSL digital certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert now a major motivation for SSL was perceived integrity weakenesses in the domain name infrastructure. however, a walkthru of the Certification Authority business processes have them requiring identification information from SSL certificate applicants ... and then they go thru an expensive, time-consuming, and error-prone process of matching that identification information against the identification information on file with the authoritative agency responsible for domain name ownership (aka the domain name infrastructure that is percieved to have integrity weaknesses motivating SSL). so the domain name CA operations are somewhat in catch-22 ... backing various aspects of DNSSEC to improve the integrity of domain name infrastructure ... on which they are dependent ... and the improvement of the itnegrity of domain name infrastructure reducing the motivation for SSL domain name certificates. part of DNSSEC can have domain name owners registering public key with the domain name infrastructure at the same time a domain name is registered. Then all future communication with domain name owners can be digitally signed (and validated with the onfile public key) as countermeasure to things like domain name hijacking (reduces possibility that somebody hijacks a domain and then applies for valid digital certificate as the "registered" domain name owner). The CA operations could also use the onfile public key to require SSL domain name certificate applicants to digital sign the application. They then can replace their expensive, error-prone and time-consuming identification matching process with a much less expensive, reliable, and efficient authentication process ... by doing a real-time retrieval of the onfile public key to validate the digital signature on the SSL domain name application. However, this also represents a catch-22 for the SSL domain name certificat industry ... since it raises the possibility that everyone could request public key retrieval piggybacked on the doman name lookup response ... aka real-time dynamic public key retrieval in place of stale static digital certificate public key distribution. http://www.garlic.com/~lynn/subpubkey.html#catch22 so while doing some of this electronic commerce stuff, i would get needled by some of the digital certificate proponents about bringing payments into the modern era by requiring digital certificates appended to all payment transactions. i would respond that the "offline" digital certificate paradigm would be reversing modern online payment transactions to at least pre-70s (back in the days of offline transactions and paper booklets of revoked cards). I view that my ridicule of such positions helped motivate the OCSP activities (but then why would payments do two different real-time transactions when it could be done all in one real-time transaction w/o certificate). The other issue was that typical digital certificate size was 100 times (two orders of magnitude) larger than typical payment transaction size. Besides appending digital certificates being redundant and superfluous, it would also increase payment transaction size by a factor of 100 times (for no useful purpose) ... misc. past posts mentioning the payment transaction bloat http://www.garlic.com/~lynn/subpubkey.html#bloat Recongizing the enormous bloat of digital certificates in payment transactions ... the financial standard group spawned a "compressed certificate" standards activity ... looking at possibly getting (useless, redundant and superfluous) appended digital certificates down to only ten times bloat. I was able to use their techniques to demonstrate how it was possible to compress digital certificates to zero bytes ... and then rather than have "certificate-less" digitally signed transactions ... it would be possible to have mandated zero-byte appended digital certificates. misc. past posts mentioning certificate-less http://www.garlic.com/~lynn/subpubkey.html#certless -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Thomas Pornin on 12 Dec 2009 16:05 According to pk <pk(a)pk.invalid>: > But let's use the SSL certificate in a real scenario, like for example > an HTTPS transaction. Is the server's public key contained in the > certificate actually used in the SSL/TLS process (for signing or > encrypting)? Or it's only the ciphersuite that client and server > negotiate that matters, and the certificate is used only for server > authentication? In SSL/TLs, the "cipher suite" is only the name which is given to the set of cryptographic algorithms which will be used to establish and secure the connection. One of those algorithms involves usage by the server of its private key, the one which corresponds to the public key stored in the serveer certificate. For instance, the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA means all of the following: -- A key exchange is performed by the client chosing a random symmetric key (the "pre-master secret") and encrypting it asymmetrically with the server public key using the RSA encryption mechanism as described in PKCS#1. -- From the pre-master secret will be derived some 128-bit keys to symmetrically encrypt exchanged data with AES (there will be one key for each direction). -- From the pre-master secret will be derived some keys to compute MAC (authentication codes) on exchanged data, with HMAC/SHA-1. Obviously, if the cipher suite mandates use of RSA then the server public key must be a RSA public key. Moreover, since that key comes within the server certificate, the client must be able to extract it from the server certificate, and use it. Server authentication does not come from the fact that the server can show a certificate. A certificate is a public object; _everybody_ can show any existing certificate. Authentication stems from the server being able to do something which _relates_ to the server public key, but which requires knowledge from the private key. For instance, in the cipher suite described above, the server is able to decrypt some data (the pre-master secret) which was encrypted with the server public key. The certificate is only a way to distribute the server public key. Conceptually, if the client already knew (with high confidence) the server public key, then even looking at the certificate sent by the server would be unnecessary. But there are millions of servers, and a client cannot know all of them in advance. Hence, the server goes to a certificate authority, and gets a certificate for its public key: a signature by the CA, which certifies that the server public key is the one which is claimed. The client knows the CA public key (there are much fewer CA than servers) and is thus able to verify the CA signature, i.e. validate the server certificate. Once this has been done, the client "knows" the server public key (with high confidence) and may use it for the SSL/TLS cryptography. Among the SSL/TLS cipher suites, some mandate use of the server public key for key exchange (as shown above); other specify that the server will compute a signature on some packets which include a Diffie-Hellman key exchange (these are the 'DHE' cipher suites). In the latter, the master secret (from which symmetric encryption and MAC keys are derived) is obtained through a Diffie-Hellman key exchange, and the server authenticates itself by producing a signature that the client can verify. There again, the client must verify the signature with regards to the server public key, and, most of the time, the client does not know in advance the server public key and must therefore extract it from the server certificate, after validation of said certificate. The 'DHE_RSA' cipher suites specify: Diffie-Hellman key exchange, with a RSA signature by the server. This requires that the server public key is a RSA key. Similarly, the 'DHE_DSS' cipher suites specify a DSS signature. (There also are some certificate-less cipher suites: the 'DH_anon'. With this suite, there is no permanent server key and no certificate is sent; but there is no server authentication either. DH_anon suites make SSL/TLS vulnerable to active hijacking attacks -- the 'man-in-the-middle' -- and are therefore not recommended. By default, Web browsers refuse to use DH_anon cipher suites.) > The underlying doubt is in fact: if the public key contained in the > certificate is generated using some esoteric algorithm like elliptic > curves, could that affect the SSL/TLS negotiations where the > certificate is used if the clients do not support EC algorithms? Yup. Namely, if the server certificate contains a public key that the client will not be able to use, then the SSL/TLS negotiation will be affected; namely, it will not work at all. In SSL/TLS, the client first announces what cipher suites it supports; the client should advertise RSA-based cipher suites only if it would be able to use a RSA public key, including decoding it from the server certificate. The server then selects a cipher suite which it supports, among those announced by the client. Obviously, the server shall refrain from selecting any cipher suite other than those for which it already has a public key packaged in a certificate which the client will probably be able to validate. For instance, if the server only has a DSS public key, and no RSA public key, then the server may only select one of the 'DHE_DSS' cipher suites. If the client does not support EC algorithms, then it will not send any EC-based cipher suite in its 'ClientHello' message; if the server only has an EC private key, then it will not find any cipher suite which both client and server will be able to use. Connection attempt is then aborted. Note that the server may own _several_ asymmetric keys, and send an appropriate certificate, depending on the cipher suites supported by the client. For instance, the server could have a RSA key _and_ a DSS key, with a certificate for each of them, and use the key and certificate corresponding to the negociated cipher suite. This would accomodate both RSA-only and DSS-only clients. A trickier point comes from certificate validation. The cipher suites tell about the server public key and how it will be used; they tell nothing about the _CA_ public key. But the client must be able to validate the server certificate, which implies prior knowledge of the CA public key, and support of the signature algorithm used by the CA to sign the server certificate. There is nothing in the ClientHello message which the client may use to tell the server which CAs it knows of and which signature algorithms it supports. The server must therefore invoke divination powers to guess in advance from which CA it should obtain a certificate, and the CA must also guess which signature algorithm is most likely to be known by the client. In practice, commercial HTTPS servers buy certificates from one of the big commercial CA which could get their root keys included in Windows (Verisign, Thawte...) and everybody (except the US government) uses RSA. Using EC-based certificates will work only when every client has support for that; and that is not the case yet. For a complete description of SSL/TLS, just go to the standard which defines it, namely RFC 5246: http://tools.ietf.org/html/rfc5246 The cipher suites which use EC cryptography are defined in RFC 4492: http://tools.ietf.org/html/rfc4492 --Thomas Pornin
From: pk on 12 Dec 2009 17:17 Thomas Pornin wrote: >> The underlying doubt is in fact: if the public key contained in the >> certificate is generated using some esoteric algorithm like elliptic >> curves, could that affect the SSL/TLS negotiations where the >> certificate is used if the clients do not support EC algorithms? > > Yup. Namely, if the server certificate contains a public key that the > client will not be able to use, then the SSL/TLS negotiation will be > affected; namely, it will not work at all. > > In SSL/TLS, the client first announces what cipher suites it supports; > the client should advertise RSA-based cipher suites only if it would be > able to use a RSA public key, including decoding it from the server > certificate. The server then selects a cipher suite which it supports, > among those announced by the client. Obviously, the server shall refrain > from selecting any cipher suite other than those for which it already > has a public key packaged in a certificate which the client will > probably be able to validate. For instance, if the server only has > a DSS public key, and no RSA public key, then the server may only > select one of the 'DHE_DSS' cipher suites. If the client does not > support EC algorithms, then it will not send any EC-based cipher > suite in its 'ClientHello' message; if the server only has an EC > private key, then it will not find any cipher suite which both client > and server will be able to use. Connection attempt is then aborted. Excellent. This (and the part that I omitted) is just the explanation I was looking for. Some traffic capturing with Wireshark shows that actually quite a lot of the ciphersuites supported by my Firefox are indeed of the EC kind for the key exchange part, eg TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) etc. along with some more conventional ones, like TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) which is the one the server (well, the server I used for testing) then chooses. (BTW, is there an official list of those ciphers, along with the numbers assigned to them, somewhere?) However, what I find strange is that OpenSSL does not seem to support any of the EC ciphersuites, at least according to the list provided here: http://www.openssl.org/docs/apps/ciphers.html Indeed, a quick check with "openssl ciphers -v" on my system shows no EC ciphers. However, it DOES support the generation and handling of EC keys from the command line, which is a bit odd then. In other words, it would seem that the problem in this case is lack of /server/ support for newer ciphers like EC, rather than (as I thought) client support. If I understand your explanation correctly, a web server linked against OpenSSL wouldn't even be able to use a SSL certificate containing an EC public key, because that would necessarily involve having support for one of the *EC* ciphers! > A trickier point comes from certificate validation. The cipher suites > tell about the server public key and how it will be used; they tell > nothing about the _CA_ public key. But the client must be able to > validate the server certificate, which implies prior knowledge of the CA > public key, and support of the signature algorithm used by the CA to > sign the server certificate. There is nothing in the ClientHello message > which the client may use to tell the server which CAs it knows of and > which signature algorithms it supports. The server must therefore invoke > divination powers to guess in advance from which CA it should obtain a > certificate, and the CA must also guess which signature algorithm is > most likely to be known by the client. In practice, commercial HTTPS > servers buy certificates from one of the big commercial CA which could > get their root keys included in Windows (Verisign, Thawte...) and > everybody (except the US government) uses RSA. Using EC-based > certificates will work only when every client has support for that; and > that is not the case yet. I suspected that was the case, but thanks for making that explicit. Many thanks again!
|
Next
|
Last
Pages: 1 2 Prev: affine cipher problem Next: Uncertainty in Privacy and Security @ IPMU 2010 |