StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POSSL Authentication with Certificates: Should the Certificates have a hostname?
text
Body
copied!<h1>Quick Version of Question</h1> <p>Gmail, TD (Canadian Bank), Royal Bank (Canadian Bank) all use ssl. When you inspect their certificates they all have </p> <pre><code>Common Name (CN) mail.google.com </code></pre> <p>Or more generally:</p> <pre><code>Common Name (CN) <url> </code></pre> <p>Is this needed to prevent man in the middle attacks? </p> <h1>Summary</h1> <p>JBoss allows clients and servers to authenticate using certificates and ssl. One thing that seems strange is that you are not required to give your hostname on the certificate. </p> <p>I think that this means if Server B is in your truststore, Sever B can pretend to be any server that they want. </p> <p>(And likewise: if Client B is in your truststore...)</p> <p>Am I missing something here? </p> <h1>Authentication Steps</h1> <p>(<a href="http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake" rel="nofollow noreferrer">Summary of Wikipeida Page</a>)</p> <pre><code>Client Server ================================================================================================= 1) Client sends Client Hello ENCRIPTION: None - highest TLS protocol supported - random number - list of cipher suites - compression methods 2) Sever Hello ENCRIPTION: None - highest TLS protocol supported - random number - choosen cipher suite - choosen compression method 3) Certificate Message ENCRIPTION: None - 4) ServerHelloDone ENCRIPTION: None 5) Certificate Message ENCRIPTION: None 6) ClientKeyExchange Message ENCRIPTION: server's public key => only server can read => if sever can read this he must own the certificate - may contain a PreMasterSecerate, public key or nothing (depends on cipher) 7) CertificateVerify Message ENCRIPTION: clients private key - purpose is to prove to the server that client owns the cert 8) BOTH CLIENT AND SERVER: - use random numbers and PreMasterSecret to compute a common secerate 9) Finished message - contains a has and MAC over previous handshakes (to ensure that those unincripted messages did not get broken) 10) Finished message - samething </code></pre> <h1>Sever Knows</h1> <ul> <li><p>The client has the public key for the sent certificate (step 7)</p></li> <li><p>The client's certificate is valid because either:</p> <ul> <li>it has been signed by a CA (verisign)</li> <li>it has been self-signed BUT it is in the server's truststore</li> </ul></li> <li><p>It is not a replay attack because presumably the random number (step 1 or 2) is sent with each message</p></li> </ul> <h1>Client Knows</h1> <ul> <li><p>The server has the public key for the sent certificate (step 6 with step 8)</p></li> <li><p>The server's certificate is valid because either:</p> <ul> <li>it has been signed by a CA (verisign)</li> <li>it has been self-signed BUT it is in the client's truststore</li> </ul></li> <li><p>It is not a replay attack because presumably the random number (step 1 or 2) is sent with each message</p></li> </ul> <h1>Potential Problem</h1> <ul> <li><p>Suppose the client's truststore has certs in it:</p> <ul> <li>Server A</li> <li>Server B (malicous)</li> </ul></li> <li><p>Server A has hostname www.A.com</p></li> <li><p>Server B has hostname www.B.com</p></li> <li><p>Suppose: The client tries to connect to Server A but Server B launches a man in the middle attack.</p></li> <li><p>Since server B:</p> <ul> <li>has a public key for the certificate that will be sent to the client</li> <li>has a "valid certificate" (a cert in the truststore)</li> </ul></li> <li>And since: <ul> <li>certificates do not have a hostname feild in them</li> </ul></li> </ul> <p>It seems like Server B can pretend to be Server A easily. </p> <p>Is there something that I am missing?</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload