CODEWITHSUNDEEP
securityauthenticationsslcertificatessl-certificate
sixtyfootersdude
sixtyfootersdude

Reputation: 27231

SSL Authentication with Certificates: Should the Certificates have a hostname?

Quick Version of Question

Gmail, TD (Canadian Bank), Royal Bank (Canadian Bank) all use ssl. When you inspect their certificates they all have 

Common Name (CN)   mail.google.com

Or more generally:

Common Name (CN)   <url>

Is this needed to prevent man in the middle attacks?

Summary

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.

I think that this means if Server B is in your truststore, Sever B can pretend to be any server that they want.

(And likewise: if Client B is in your truststore...)

Am I missing something here?

Authentication Steps

(Summary of Wikipeida Page)

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

Sever Knows

Client Knows

Potential Problem

It seems like Server B can pretend to be Server A easily.

Is there something that I am missing?

Upvotes: 7

Views: 3762

Answers (2)

Henri
Henri

Reputation: 5113

I think you're missing something, but I'm not sure if I understand your reasoning.

However, when server B tries to launch a man in the middle attack, you say that it has a public key. This is true, but to setup a ssl connection, you should also have a private key belonging to that public key. Moreover, the certificate used is coupled to the dns name (in case of https). So a client tries to connect to A, he types in www.a.com. Since we assume that B does not know the private key of A, he will have another keypair. He could never receive a valid (i.e. trusted) certificate from a major CA that is coupled to a domain he does not own.

So B could never get a certificate with common name www.A.com, for this reason, B could not perform a man in the middle attack.

Upvotes: 2

Michael Howard-MSFT
Michael Howard-MSFT

Reputation: 3290

Can you point to some text that says JBoss doesn't need a hostname in the cert, or is it simply your observation? I assume by 'hostname' you mean the Common Name (CN) or Distinguished Name (DN)??

Normally an application should check an X.509 cert for:

Valid date range
Usage (eg; server auth)
Chains to a trusted root
CN == DNS name of target host (it might be another name, not just DNS)
Not revoked (using a CRL or OCSP)

Technically, an app can choose to ignore any of these and simply indicate that all is well with the cert.... but that's bad :)

Upvotes: 2

Related Questions