File talk:Ssl handshake with two way authentication with certificates.svg

Nearly two years ago, it was pointed out that this diagram is wrong, and it is still wrong.

The client certificate is not verified by re-sending it, encrypted with the client certificate private key, as indicated in the diagram. Encrypting an entire certificate with a private key is not practical, and this message would be subject to replay (and therefore impersonation of the client) by any server that has ever seen it.

The client certificate is verified by sending a signed hash of all of the exchanged handshake messages, as indicated in section 7.4.8 of RFC 4346.

—Preceding unsigned comment added by 67.170.34.34 (talk) 00:26, 1 January 2010 (UTC)[reply]

This diagram is missing a few things:

Message direction. There is no indication of the direction of messages.
"demand client zertificate" is really called "CertificateRequest"
Immediately after "demand client zertificate", there should be a "ServerHelloDone" message.
Given that the client response to the ServerHello consists of 5 messages, the server generally does not check the client certificate immediately upon receipt of that message.
Client certificate is shown as being sent twice, "client certificate" and "client certifikate (encrypted with Private Key Client)". This is wrong. The client certificate is sent over once, and is not encrypted with any private key. The client certificate includes the public key.
The "change to encrpted connection with (MS)", is really the ChangeCipherSpec record.
The "end SSL handshake", is really the Finished handshake message.

This diagram should not be used.

Also not clear what the acronyms such as "RNc" mean : diagram needs a legend to explain these.Ekoontz (talk) 23:23, 18 July 2008 (UTC)[reply]

Regarding issue #1: There are arrow-heads in the document, but it appears they are not rendered by all SVG viewers. The drawing program "Inkscape" renders them, while the Safari v3.2.1 web browser does not currently render them. It is likely that other WebKit-based browsers like Safari will also have trouble rendering the arrow-heads. 164.67.97.133 (talk) 20:07, 6 May 2009 (UTC)[reply]

Note that FireFox 3.0.13 (on Linux) does not display the arrows, either. -pinkgothic (talk) 10:57, 9 September 2009 (UTC)[reply]

Note that FireFox 3.5.3 on Windows XP fails to display the arrow heads on the straight lines (though the curved arrows are displayed correctly). - Paul (talk) 10:43, 11 September 2009 (UTC)[reply]

I've logged a bug report with Mozilla. See bug 519912. - Tbsdy lives (formerly Ta bu shi da yu) ^talk 06:35, 1 October 2009 (UTC)[reply]

I was informed what the issue was. It's as follows:

Firefox has the correct rendering, I believe, and it renders the same in Batik. The marker for the arrowheads that aren't rendering is #Arrow2Lend. It just has <path> on it, with no 'fill' property. However, the root SVG element has class="st24", and the style sheet in the document has a rule for .st24 that sets fill to 'none'. So the marker isn't painting the fill of its path.

So it was pretty simple to edit the file in a text editor to fix it. - Tbsdy lives (formerly Ta bu shi da yu) ^talk 13:31, 1 October 2009 (UTC)[reply]