On Wed, Sep 17, 2008 at 10:56:10AM -0700, Ryerse, Mike (DIS) wrote:
> I haven't added a private key to either application. Could Ethereal be
> making an assumption that there is a certificate request based on
> previous packets of the SSL negotiation? It seems to me like packet 39
> is not encrypted and no assumption is made, and even the first byte of
> the "encrypted handshake message" is 0d, or 13, which is how Ethereal is
> recognizing this as a certificate request.
Ah, I now understand what caused the confusion :-)
There was a bug in the SSL-dissector that it did not keep track of
whether the data was already encrypted or not. As soon as the dissector
recognized a certain SSL-handshake message, it assumed that it was
still in unecrypted state. It would then read the next octets as the
expected length field, which results in a [malformed] packet as that
length would almost always be longer than the actual data in the trace.
When looking at the frames, it looks more like frame 30 has the
(encrypted) certificate request in it.
> The IIS server is setup so that it is only protecting certain sites on
> the same listener with required client certificate authentication.
> There are other sites on the same listener that do not require client
> certificate authentication. I think it makes sense because by the time
> the SSL negotiation takes place, IIS does not know exactly what site
> (URI) is being requested. It only knows the hostname/port (listener).
> So if you have some sites on the same listener that require client
> certificate authentication, and some that don't or are optional, it
> needs to let all clients negotiate an SSL session without requiring a
> client certificate, and when it gets to the point where the URI is
> passed, then the server initiates a new SSL negotiation that requires a
> client certificate, and this request could be encrypted, not allowing
> Wireshark to see the certificate request. This still seems odd to me
> though because other http servers would do the same thing by issuing a
> client certificate (packet 6 in my capture). So I think this is just a
> Microsoft way of doing things.
Check! I have seen this same behaviour on IIS before and it does indeed
make sense.
> It is a test system, so I can get the private key of the server for a
> new capture. It'll take me a while to get the key correctly loaded into
> Wireshark, and hopefully we're using RSA because it seems that is all
> Wireshark support.
Well, openssl is your friend when converting keys from one file format
to another. Of course it won't change the protocol used to make the
key ;-)
If you have trouble converting it, let me know, maybe I can help...
Cheers,
Sake