SSL certificates and keys
pk
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.
Will Dickson
> 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.
Anne & Lynn Wheeler
pk <p...@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
Thomas Pornin
> 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
pk
>> 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!
Thomas Pornin
> (BTW, is there an official list of those ciphers, along with the numbers
> assigned to them, somewhere?)
RFC 5246 and 4492. See my previous message (at the end).
--Thomas Pornin
pk
Ah, I was just about to read them :)
Thanks! (and to all the other respondents as well)
Anne & Lynn Wheeler
ssl/tsl ... my rfc index
http://www.garlic.com/~lynn/rfcietff.htm
click on "Term (term->RFC#)" in the "RFCs listed by" section, then
click on "TLS" in the "Acronym fastpath" ... brings up:
transport layer security (TLS )
see also encryption , security
5734 5590 5539 5489 5487 5469 5430 5425 5422 5421 5289 5288 5281 5246
5238 5216 5114 5081 5077 5054 5018 4934 4851 4785 4762 4681 4680 4642
4572 4513 4507 4492 4366 4347 4346 4279 4261 4217 4162 4132 3943 3788
3749 3734 3546 3436 3268 3207 2847 2830 2818 2817 2716 2712 2595 2487
2246
...
clicking on RFC number, brings up RFC summary in lower frame ... aka:
5246 PS
The Transport Layer Security (TLS) Protocol Version 1.2, Dierks T.,
Rescorla E., 2008/08/15 (104pp) (.txt=222395) (Obsoletes 3268, 4346,
4366) (Updates 4492) (Refs 793, 1321, 1948, 2104, 2246, 2785, 3268,
3280, 3447, 3526, 3749, 3766, 4086, 4279, 4302, 4303, 4307, 4346, 4366,
4492, 4506, 5081, 5116) (Ref'ed By 5247, 5288, 5289, 5327, 5333, 5352,
5353, 5355, 5369, 5370, 5371, 5387, 5404, 5408, 5409, 5415, 5422, 5425,
5430, 5440, 5458, 5469, 5479, 5482, 5486, 5487, 5489, 5505, 5539, 5550,
5567, 5577, 5582, 5590, 5616, 5626, 5630, 5636, 5677, 5691, 5697, 5734)
...
Clicking on the ".txt=nnn" field retrieves the actual RFC; normally in
the upper frame ... but with browser-tabs ... can bring RFC into other
tabs.
I do updates & updated-by, I've also done some amount of scanning rfc
text to come up with REFs (and therefor REF'ed-By).
i.e.
4492 I
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS), Blake-Wilson S., Bolyard N., Gupta V., Hawk C., Moeller
B., 2006/05/16 (35pp) (.txt=72231) (Updated by 5246) (Refs 2246, 3268,
3279, 3280, 4346, 4366) (Ref'ed By 5114, 5246, 5289, 5430, 5479, 5489)
David Thompson
<snip>
> 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.
>
disabled for TLS by default, and component-matching doesn't get them
for some reason; I think I did track this down at one point, but don't
remember what I found. Instead your cipher selection string aka
cipherlist must specify either the exact suite name(s) individually or
'ECCdraft' to get all of them.
> However, it DOES support the generation and handling of EC keys from the
> command line, which is a bit odd then.
>
And CSRs and certs (req, x509, ca); and I assume CRLs, but didn't
test. And the EVP (or lowlevel) API supports them. It's only the TLS
suites that default off.
> 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!
>
It must enable at least one of the EC suites, which was also offered
by the client. And have the cert and matching key, like all PK. The
algorithms (ECDSA and ECDH aren't exactly 'ciphers') are there.
I assume you mean 'use' to cover only server authentication.
Any openssl program -- client or server -- can use a parent (CA) cert
with an EC(DSA)-key to verify an ECDSA-signed child cert -- which
child cert could be for an entity using RSA or DSA authentication.
I'd be a bit surprised if anyone serious would think it makes sense
for an EC-using (and implicitly EC-requiring) CA to certify
non-EC-using parties, but I tested and technically it works.