Jack Varga wrote:
> My understanding is SSL assumes source info is spoofed.
I don't agree that SSL makes any such assumption, but I don't think it's
relevant to what follows.
> 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.
What you write is true about a server. A server resumes an SSL session
based purely on SSL session ID and not on IP address or port of the client.
It is not true about a client however. A client remembers the SSL session
ID associated with each server that it has contacted in the recent past.
When a client revisits a server, it sends the SSL session ID that it last
used with that server to that server. The server may reuse that old
session, or it may establish a new one which replaces the old one. If the
server responds with a new session ID (not reusing the old one), the client
removes the old SSL session information for that server from the client's
memory of SSL sessions, and replaces that info with the new session ID.
Either way, the client associates the session with that server, and not
with any other server.
It is an error for an SSL client to send an SSL session ID to a server
when that session was established with another server.
> 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.
They tie SSL session IDs to servers. The SSL protocol has the client
send its SSL session ID to the server before it receives any messages
from the server. SO, the client must choose the SSL session ID that it
sends to the server based on information it has about the server before
it receives any data from the server. And the only such information
is the aforementioned triplet (hostname, IP address, port).
If the SSL protocol had the server speak first, and the server started
by telling the client some globally unique server ID number, then the
client might be able to choose the SSL session Id that it sends to the
server based on something other than that triplet. But SSL doesn't
work that way.
> If they truly
> supported SSL they would provide a mechanism to force
> a cached ssl session_id to be used, regardless of url.
Again, the crucial item to understand is that the client should only send
an SSL session ID to a server when it resonably expects that server to be
the same server with which it has previously had that particular SSL
session. The https client has no other basis than those mentioned above.
> 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.
The browser is able to do something like that when proxies are involved.
The browser is able to decouple the information about the SSL session from
the IP address of the proxy. But this happens only when it is aware of the
proxy.
> -jv
Actually, I can see the IP address being taken entirely out of the picture,
and the client relying solely on hostname and port. But without IP address
or hostname, the browser has no basis upon which to know which of the many
SSL session IDs it is remembering to send to the server.
--
Nelson Bolyard Sun / Netscape Alliance
Disclaimer: I speak for myself, not for Netscape
