Wireshark-users: Re: [Wireshark-users] CertificateRequestdoesn'tseemproperly displayed
Sake, you are right about the bug being in Ethereal 1.1.0, where it
thinks the data is not encrypted when it really is. Now that I have the
server's private key loaded, I can see now that in fact the server is
requesting a certificate in packet 18 and 36. So I have learned that
yes, with IIS 6.0 set to require client certificates, it does not even
request a client certificate until an SSL session is established and an
HTTP get is issued. At that point the server knows what is being
requested and sends a "Hello Request", re-negotiating a new SSL session,
at which point it does request a certificate. You just don't see it
because it is encrypted.
So for production servers where I can't get private keys this will be
difficult to troubleshoot at the wire, but I can still use a browser for
some cases.
I am thinking though, since the browser is able to decrypt the message
without using the server's private key, shouldn't this theoretically
also be possible with wireshark somehow?
Anyway, thanks for all your help. Learned a lot today :)
Michael Ryerse
-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sake Blok
Sent: Wednesday, September 17, 2008 3:09 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] CertificateRequestdoesn'tseemproperly
displayed
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
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-users
