HTTPS, SSLSockets and Symmetric Key renegotiation

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

HTTPS, SSLSockets and Symmetric Key renegotiation

Arturo Zambrano
Hi All.
 I'm developing an application (now running on jetty 5.1.2) which has
strong security requirements.
 In particular, besides using HTTPS, a periodical evolution of symmetric
keys is needed. AFAIK, the symmetric keys are negotiated during
the SSL/TLS handshake, and remain the same during connection lifespan
(which can be quite long when using HTTP 1.1).

What I need is that keys, used by existing SSLSocket, to be renegotiated.

Do you know how to do this? Has anyone faced this problem?

IMHO, the only way to do this is  to extend Jetty so that an
startHandshake() is invoked on the instanciated  SSLSockets. But I don't
know if it would have some negative side-effect, such as an HTTP error.

Is there other, more elegant, alternative approache?
May be I'm missing some configuration trick...

Any advice regarding this topic is welcome.

Thank you in advance.

arturo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS, SSLSockets and Symmetric Key renegotiation

Chris Haynes
See embedded responses...

"Arturo Zambrano" asked:


>Hi All.
> I'm developing an application (now running on jetty 5.1.2) which has
>strong security requirements.
> In particular, besides using HTTPS, a periodical evolution of symmetric
>keys is needed. AFAIK, the symmetric keys are negotiated during
>the SSL/TLS handshake, and remain the same during connection lifespan
>(which can be quite long when using HTTP 1.1).

Not quite right...
(1) the SSL session lasts as long as the client and server want it to (e.g. as
long as the client browser is open).
This can extend over many HTTP 1.1 'connections'

(2) The SSL spec allows the SSL session to be re-negotiated at any time. My
understanding is that
this often takes place in a way which does not disrupt any carried data (e.g.
HTTP requests / responses).
It all happens deep within the JVM's SSL implementation - invisible to Jetty.
There is, presumably, a policy timer somewhere which decides how ofter to change
keys.

>What I need is that keys, used by existing SSLSocket, to be renegotiated.

>Do you know how to do this? Has anyone faced this problem?

>IMHO, the only way to do this is  to extend Jetty so that an
>startHandshake() is invoked on the instanciated  SSLSockets.

That's my HO as well, at least from the server end of things.

>But I don't
>know if it would have some negative side-effect, such as an HTTP error.

It _ought_ not to.

>Is there other, more elegant, alternative approache?
>May be I'm missing some configuration trick...

Not that I know of. It might just be worth delving around within the
specification of Sun's SSL implementation to see if there is any policy setting
which does exactly what you want - i.e. forces key renegotiation at a frequency
of your choice. I know it's not visible at the API level, but there may be some
obscure settings in the security-related .property files that come with the JVM.

This: http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html
is the place to start your search.

>Any advice regarding this topic is welcome.

>Thank you in advance.

>arturo

HTH

Chris Haynes







-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS, SSLSockets and Symmetric Key renegotiation

Arturo Zambrano
Hi Chris,
 thanks for your reply ... I have some comments below....

On 2/13/06, Chris Haynes <[hidden email]> wrote:

> See embedded responses...
>
> "Arturo Zambrano" asked:
>
>
> >Hi All.
> > I'm developing an application (now running on jetty 5.1.2) which has
> >strong security requirements.
> > In particular, besides using HTTPS, a periodical evolution of symmetric
> >keys is needed. AFAIK, the symmetric keys are negotiated during
> >the SSL/TLS handshake, and remain the same during connection lifespan
> >(which can be quite long when using HTTP 1.1).
>
> Not quite right...
> (1) the SSL session lasts as long as the client and server want it to (e.g. as
> long as the client browser is open).
> This can extend over many HTTP 1.1 'connections'
>

You mean that several HTTP 1.1 connections may use the same encryption settings,
so if one side (either client or server) a renegotiation  might not happen?


> (2) The SSL spec allows the SSL session to be re-negotiated at any time. My
> understanding is that
> this often takes place in a way which does not disrupt any carried data (e.g.
> HTTP requests / responses).

Yes, as example OpenSSL provides renegotiation settings based on time
and amount of transferred data

> It all happens deep within the JVM's SSL implementation - invisible to Jetty.
> There is, presumably, a policy timer somewhere which decides how ofter to change
> keys.
>
> >What I need is that keys, used by existing SSLSocket, to be renegotiated.
>
> >Do you know how to do this? Has anyone faced this problem?
>
> >IMHO, the only way to do this is  to extend Jetty so that an
> >startHandshake() is invoked on the instanciated  SSLSockets.
>
> That's my HO as well, at least from the server end of things.
>
> >But I don't
> >know if it would have some negative side-effect, such as an HTTP error.
>
> It _ought_ not to.
>
> >Is there other, more elegant, alternative approache?
> >May be I'm missing some configuration trick...
>
> Not that I know of. It might just be worth delving around within the
> specification of Sun's SSL implementation to see if there is any policy setting
> which does exactly what you want - i.e. forces key renegotiation at a frequency
> of your choice. I know it's not visible at the API level, but there may be some
> obscure settings in the security-related .property files that come with the JVM.
>
> This: http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html
> is the place to start your search.

thank you, I will report any useful thing, just in case someone is interested.

regards.
arturo

>
> >Any advice regarding this topic is welcome.
>
> >Thank you in advance.
>
> >arturo
>
> HTH
>
> Chris Haynes
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS, SSLSockets and Symmetric Key renegotiation

Chris Haynes
"Arturo Zambrano" responded:
...

>> Not quite right...
>> (1) the SSL session lasts as long as the client and server want it to (e.g.
>> as
>> long as the client browser is open).
>> This can extend over many HTTP 1.1 'connections'
>

>You mean that several HTTP 1.1 connections may use the same encryption
>settings,

Yes - but obviusly the encryption sequence 'evolves', no two HTTP 'connections'
will be encrypted in the same way. It's not as if the SSL session were re-set to
the initial keys after each HTTP connection.

From the encryption layer POV, its as if all the HTTP traffic from several HTTP
'connections' were one long bit stream. Indeed SSL is totally unaware of the
nature of the HTTP traffic it is carrying.

>so if one side (either client or server) a renegotiation  might not happen?

Not sure what you mean here.

I believe either end of the connection can demand a re-negotiation of the SSL
session credentials, so the more paranoid end can impose its will.


Chris





-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS, SSLSockets and Symmetric Key renegotiation

Arturo Zambrano
Chris Haynes wrote:

> "Arturo Zambrano" responded:
> ...
>
>>> Not quite right...
>>> (1) the SSL session lasts as long as the client and server want it to
>>> (e.g. as
>>> long as the client browser is open).
>>> This can extend over many HTTP 1.1 'connections'
>>
>
>> You mean that several HTTP 1.1 connections may use the same encryption
>> settings,
>
> Yes - but obviusly the encryption sequence 'evolves', no two HTTP
> 'connections' will be encrypted in the same way. It's not as if the SSL
> session were re-set to the initial keys after each HTTP connection.
>
>> From the encryption layer POV, its as if all the HTTP traffic from
>> several HTTP
> 'connections' were one long bit stream. Indeed SSL is totally unaware of
> the nature of the HTTP traffic it is carrying.
>
>> so if one side (either client or server) a renegotiation  might not
>> happen?
>
> Not sure what you mean here.
sorry I forgot the verb :)

>
> I believe either end of the connection can demand a re-negotiation of
> the SSL session credentials, so the more paranoid end can impose its will.


Just to let you know that the proposed solution worked fine.
Invoking and startHandshake() on an already in use SSLSocket
causes the renegotiation of the encryption settings without
side-effects ...  no HTTP error :D


thanks for your helpful comments.

regards.
arturo




>
>
> Chris
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support