If you are eavesdropping an ssl session you are not supposed to know
the shared secret between the client and the server in order to avoid
you decrypting what goes through
client and server. The "not allowing eavsdropers" to see the clear
text exchange between client and server happens to be the reason why
people uses SSL, if they did not care about someone reading the data
that is being passed between cleint and server they propably won't be
using SSL.
The client knows the shared information used to decrypt that the
client negotiated with the server using the server's public key.
Wireshark is not the client, it's the eavesdropper, so it does not
know that information, so in order to be able to obtain that it needs
to know the server key to be able to decrypt it.
On 8/10/07, Derek Shinaberry <wireshark@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Can someone help me understand why you must have the server's private
> key in order to be able to decrypt the session between the client and
> the server? It seems to me that if the server and client can conduct
> the session without the client ever knowing the server's private key,
> then a capture of the session on the client's side ought to be able
> to decrypt the session using just what is in the SSL handshake
> exchange. What don't I understand about the process that precludes
> this behavior?
>
> Thanks,
> Derek
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
Propertarianism joined to capitalist vigor destroyed meaningful
commercial competition, but when it came to making good software,
anarchism won.
-- Eben Moglen
