- From: Henry Story <henry.story@bblfish.net>
- Date: Sat, 22 Jan 2011 18:24:06 +0100
- To: "Yngve N. Pettersen" <yngve@opera.com>
- Cc: foaf-protocols <foaf-protocols@lists.foaf-project.org>, Nathan <nathan@webr3.org>, WebID XG <public-xg-webid@w3.org>
I think the server certificate is always sent in the clear though... Here is a nice article on the first few milliseconds of an HTTPS connection http://www.infoq.com/articles/HTTPS-Connection-Jeff-Moser but it does not cover the client certificate side. Henry On 22 Jan 2011, at 17:46, Yngve N. Pettersen wrote: > On Fri, 21 Jan 2011 19:09:09 +0100, Nathan <nathan@webr3.org> wrote: > >> Just a quick sanity check, TLS connections are encrypted (with a random >> key) or suchlike, before any certificates are passed, yes? (as in, all >> data, including certificates, are encrypted over the wire, using keys >> not found in the certificates). > > That depends on the server configuration, there is no such restriction in > the TLS protocol. > > A TLS client certificate can be sent in the initial handshake, or in a > later renegotiation of the connection. In the latter case it is often > triggered by the requested URL being in a specific group of URLs that > require authentication. > > Please note that if the server requests authentication during > renegotiation then the server SHOULD be patched against the TLS Renego > vulnerability (patched by RFC 5746), and it should require clients to be > patched against that problem, too. > > For reference, the client certificate keys are only used to sign a hash of > the handshake messages, the result becomes part of the final handshake > hash. They are not used as part of the keyexhange. > > > -- > Sincerely, > Yngve N. Pettersen > > ******************************************************************** > Senior Developer Email: yngve@opera.com > Opera Software ASA http://www.opera.com/ > Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 Social Web Architect http://bblfish.net/
Received on Saturday, 22 January 2011 17:24:47 UTC