How does bidirectional authentication using SSL work?

I'm assuming the threat model is that there may be a man-in-the-middle attacker between Alice and Bob, and that Alice and Bob are not on the same trusted sub-net. That's what SSL/TLS is designed to protect against, and that's why Alice should check Bob's certificate in your example (at least).

From Bob's point of view, checking that Alice's request come from a known IP address isn't of much use. Attackers could forge and alter packets to make them look like they come from the IP address they wish. Subsequently, DNS lookups are useless too: all you'd need is to make sure you forge the packets to use an IP address with the correct DNS entry.

When Bob requests a client-certificate from Alice during SSL/TLS handshake, this will also make Alice send her certificate and use her private key during the SSL/TLS handshake to assert her identity. When the handshake has completed successfully, Bob will then know that Alice has the private key for that certificate and will have to verify it trusts this certificate.

Whether or not the request comes from behind a proxy or not doesn't matter when you're using SSL/TLS. An HTTP proxy merely tunnels the SSL/TLS connection from the original client to the target server.

What matters to Bob is how he's going to verify Alice's certificate. Typically, this will be done using a PKI in the same way as Alice verified Bob's certificate, although this needs not be the same CA as Bob's (it needs to be something that Bob trusts). Note that this doesn't need to be using a PKI either. It's possible to verify the certificate against a given list (if Alice and Bob have met before, for example), but this can be a bit more complex since Bob may have to tweak the accepted issuers list it sends (e.g. send an empty one, which is explicitly allowed by TLS 1.1, but not specified either way in previous versions, see Certificate Request message) and use custom code to verify that certificate. (I've implemented this sort of scheme in the past and it works fine.)

There is an exception to this when using what I'd call "MITM proxy servers", that is proxy servers that are configured to spoof the actual SSL/TLS server by inserting their own certificate (see Squid's SSL Bump). In this case the certificate Alice sees wouldn't come from Diginotar, but from another CA (typically a corporate CA when this is done on a corporate LAN).

Although Alice might allow herself to trust such a MITM proxy, using SSL/TLS client-certificate authentication would make Bob realise there is a MITM and the connection would fail. This is because Alice is supposed to sign the entire SSL/TLS handshake (as seen by both Alice and Bob) in her CertificateVerify message to authenticate with a client-certificate. Since the MITM proxy would have replaced Bob's certificate, the signatures sent by Alice and Bob wouldn't match.

It would depend on the specific implementation.

In general, Alice would act as a client to Bob. If Bob is expecting only other authorised servers to connect, Bob would check the certificate for validity including expiry, against the issuers CRL and perform a reverse lookup against the name. If Bob is expecting a user client the reverse lookup will probably be skipped or only used for logging.

If Bob expects that Alice is connecting from a known trusted host then Bob would expect Alice’s IP address to match the DNS record. It doesn’t matter to Bob that Alice is behind a proxy, and Bob will only see the proxy’s IP address. So alice.in.wonderland.com would need to be configured to the external IP address of the proxy.

The key part however is this:

1. Bob will have Alice’s public key already mapped to an ID of some sort that will be used to grant access to Bob’s resources.
2. Bob and Alice will challenge each other sending a message to each other that each can only decrypt with their private key. Thus proving they have the certificate that is known and trusted by each side.

Also note: If Alice is behind a proxy, the proxy needs to either have Alice’s private key (so the proxy can talk with Bob on Alice’s behalf) or must pass through Alice’s connection without altering its contents.

Additional reference http://en.wikipedia.org/wiki/Transport_Layer_Security or http://tools.ietf.org/html/rfc5246 for specific technical details.

Hope that helps.

Not quite. After the SSL handshake completes, Bob knows that he is talking to someone that Verisign has certified as alice.in.wonderland.com. What Bob does with this information at this point is up to him, and will depend upon the particular application. Some examples:

• Bob might have a whitelist of clients who are allowed to connect. Then Bob would look up alice.in.wonderland.com in this list. (Bob could alternatively have a whitelist of public keys, but client certs might make things easier for Bob to manage, because he can now enter in human-readable values in his whitelist.)

• Bob might treat alice.in.wonderland.com as Alice's username and log her into her account. In other words, Bob might have a database with a list of users; for each user, it would have the user's name (as found in the user's cert) and all the information associated with that user. Once Bob receives a connection from someone with name N, Bob can look up N in the table and automatically log the client in as N. When someone creates a new account, Bob can automatically create a new account with the name found in their cert (assuming one doesn't already exist). The result is that users can log into Bob's service, without needing to enter in a username or password; their client cert is used to authenticate them.

Again, this is application-dependent; it depends upon what Bob wants to know about the identity of the computer he is talking to. There is no single answer.