That is exactly what I'm requesting, thanks.
My understanding is SSL provides mechanisms for
reestablishing SSL sessions with a new socket connection.
If what you say is true, browsers (in general) don't
include a mechanism for exploiting this SSL capability.
More specifically, if browsers were truly compatible
with SSL, there would be a way to force the browser
to send a new ClientHello using the session_id in it's
cache.
I have a hard time believing this partly because I
don't want to, but mostly because SSL was originally
contrived for http. Why else would SSL purposely segregate
the socket layer from the session layer and then not
provide a means for allowing the major application that
uses it to exploit that capability???
The scenario I describe doesn't change the endpoints
(browser and server) involved in a session. Instead,
it only involves controlling the route that is taken
to get from end to end.
Although this may sound like attempting a man in the
middle attack, that is not the case. Instead,
the intent is to handshake an SSL session outside of a
gateway system, then move the routing of that session
between two gates that convert the frames to streaming
frames. At the back gate, the frames are converted
back. The payload is untouched.
In other words, the browser follows a new secure link
that routes request frames to the front end of the gateway
service. Instead of sending a new ClientHello, I want
to send a ClientHello with the old session_id.
More thoughts...?
-jv
Terry Hayes wrote:
> I think you are requesting a way to have a browser establish an SSL
> connection using a previous SSL session, but use a different host and/or
> port number. Apparently the new host/port is actually at the same site
> and can share the session data (cryptographic keys in particular).
>
> There is no mechanism to indicate that the browser should do this. The
> session information for SSL is typically tied to a particular host an
> port number. New connections to other URLs will always generate a new
> session id.
>
> Terry
>
> Jack Varga wrote:
>
>> I hope this is the right place to ask. If not, please redirect me.
>>
>> SSL includes a provision for reestablishing SSL sessions over a new
>> socket
>> by simply enabling session resumption on the server, and having the
>> client
>> send a new ClientHello that includes the existing ssl session_id.
>>
>> When the client is a browser, (i.e., Mozzilla), how can I force the
>> browser
>> to do this?
>>
>> Is there something I can embed in a server response (i.e., html) to tell
>> the the browser to use the same session_id, but direct it to a
>> different URL?
--
Jack Varga SMTS 303.413.8800 x1082 wk
[EMAIL PROTECTED]
Boulder, Colorado
