[I am posting this message on behalf of Jack Varga, who wrote me saying
that the news server won't let him post this. -- Nelson]
Jack Varga wrote:
Terry, Nelson, thanks.
It's not that I don't think browsers routinely use SSL
session resumption features. I know they do. What
I'm having difficulty understanding is why would SSL
include a provision for separating socket connections
from an SSL session if a browser can't explicitly
exploit that?
My understanding is SSL assumes source info is spoofed.
As a result, the security in an SSL session isn't
tied to the binded socket. Instead, SSL security is
tied to the improbable scenario that an attacker could
possess both the client's and browser's encryption scheme
within the allotted time constraint. As a result, an
SSL server could care less about the src ip/port
of the re-connecting client. It relies solely on
session_id and the client's encryption key code. If the
client doesn't have the right key code, the session will
never be resumed.
The problem is that browsers appear to do just the
opposite! That is they tie the ssl session_id to socket
information and the do it automagically. If they truly
supported SSL they would provide a mechanism to force
a cached ssl session_id to be used, regardless of url.
So that's what I'm looking to do; force a new ClientHello
using a cached session_id to a new fqdn. Actually,
the new fqdn in the resumed session is the front
end of a gated network. The ultimate destination is the
same SSL server. Another way to think of it is I'm trying
to force the resumed session to take a new route which
is controlled via name resolution.
-jv
