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

• The client has the public key for the sent certificate (step 7)

• The client's certificate is valid because either:

  • it has been signed by a CA (verisign)
  • it has been self-signed BUT it is in the server's truststore

• It is not a replay attack because presumably the random number (step 1 or 2) is sent with each message

Client Knows

• The server has the public key for the sent certificate (step 6 with step 8)

• The server's certificate is valid because either:

  • it has been signed by a CA (verisign)
  • it has been self-signed BUT it is in the client's truststore

• It is not a replay attack because presumably the random number (step 1 or 2) is sent with each message

Potential Problem

• Suppose the client's truststore has certs in it:

  • Server A
  • Server B (malicous)

• Server A has hostname www.A.com

• Server B has hostname www.B.com

• Suppose: The client tries to connect to Server A but Server B launches a man in the middle attack.

• Since server B:

  • has a public key for the certificate that will be sent to the client
  • has a "valid certificate" (a cert in the truststore)
• And since:
  • certificates do not have a hostname feild in them

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

Is there something that I am missing?