SSL Session Resume?

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

SSL Session Resume?

Ben Castellucci

Greetings.

This may indeed be the wrong place to bring this up. If so, could someone kindly direct me to the right place (be that a feature request or issue or whatever)?

Also, I will disclose I am not an expert in any way regarding how Java handles SSL communication so I may be completely off base here.

However, I was perusing the source and noticed in SVNSocketFactory.java, method createSSLContext(), it looks like a brand new SSLContext object is created every time. This ends up that the entire SSL handshake must be repeated for each and every SVN operation because the built in support for session resume is not able to function.

If the SSLContext object were stored in some way, possibly a static variable or something, that should allow SSL session resume which would avoid this issue.

I realize this would have no benefit for command line as it's a new JVM each time, however it would benefit GUI clients immensely. It would greatly speed up operations and make using SVN over SSL orders of magnitude more pleasant.

Let me know any thoughts.

Thanks!
Ben

Reply | Threaded
Open this post in threaded view
|

Re: SSL Session Resume?

Ben Castellucci

Bump...

Any thoughts about making a change like this?

On Sep 30, 2015 10:46 AM, "Ben Castellucci" <[hidden email]> wrote:

Greetings.

This may indeed be the wrong place to bring this up. If so, could someone kindly direct me to the right place (be that a feature request or issue or whatever)?

Also, I will disclose I am not an expert in any way regarding how Java handles SSL communication so I may be completely off base here.

However, I was perusing the source and noticed in SVNSocketFactory.java, method createSSLContext(), it looks like a brand new SSLContext object is created every time. This ends up that the entire SSL handshake must be repeated for each and every SVN operation because the built in support for session resume is not able to function.

If the SSLContext object were stored in some way, possibly a static variable or something, that should allow SSL session resume which would avoid this issue.

I realize this would have no benefit for command line as it's a new JVM each time, however it would benefit GUI clients immensely. It would greatly speed up operations and make using SVN over SSL orders of magnitude more pleasant.

Let me know any thoughts.

Thanks!
Ben

Reply | Threaded
Open this post in threaded view
|

Re: SSL Session Resume?

Alexander Kitaev-4
Hello Ben,

Thank you for sharing your concern. However, with HTTP the [ssl]socket is reused for each subsequent HTTP request, so I do not think SSLContext is recreated for each request. Whether connection is persistent or not depends on HTTP Keep-Alive header value (and that depends on the server settings), so I think that SSLContext might be created a few times during SVN operation like update or getDir, but it should not happen for each HTTP request.

Do you experience different behavior?

Thanks!

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

On Thu, Oct 8, 2015 at 1:31 AM, Ben Castellucci <[hidden email]> wrote:

Bump...

Any thoughts about making a change like this?

On Sep 30, 2015 10:46 AM, "Ben Castellucci" <[hidden email]> wrote:

Greetings.

This may indeed be the wrong place to bring this up. If so, could someone kindly direct me to the right place (be that a feature request or issue or whatever)?

Also, I will disclose I am not an expert in any way regarding how Java handles SSL communication so I may be completely off base here.

However, I was perusing the source and noticed in SVNSocketFactory.java, method createSSLContext(), it looks like a brand new SSLContext object is created every time. This ends up that the entire SSL handshake must be repeated for each and every SVN operation because the built in support for session resume is not able to function.

If the SSLContext object were stored in some way, possibly a static variable or something, that should allow SSL session resume which would avoid this issue.

I realize this would have no benefit for command line as it's a new JVM each time, however it would benefit GUI clients immensely. It would greatly speed up operations and make using SVN over SSL orders of magnitude more pleasant.

Let me know any thoughts.

Thanks!
Ben


Reply | Threaded
Open this post in threaded view
|

Re: SSL Session Resume?

Ben Castellucci

Thanks Alexander.

This is why i stated up front i am not an expert.

:)

However, i did take a little time to try and prove my theory. I grabbed the latest SVNKit source, built it and installed the plugin in Eclipse (coupled with Subclipse) then proceeded to debug it. Everytime i looked at the SSLSession object gleaned from the SSLSocket object in HTTPConnection class, method request(), it's isSessionResumption member is always false, always.

Further, here are some examples of behavior i see:

  1. When going to SVN Repository Exploring perspective in Eclipse and simply navigating the tree structure, the full-deal SSL handshake is performed every time i expand a folder.

  2. When shift-clicking and checking out multiple projects, the full-deal SSL handshake is performed prior to checking out each one.

  3. (This is one of the most painful) when reverting local changes, the full-deal SSL handshake is performed for EACH file being reverted.

These are just a few examples.

From what you say below and what i have experienced, most likely some of this is coming from the Subclipse plugin and how it is utilizing the SVNKit libraries. Maybe it's throwing away things and starting fresh when it shouldn't.

However, i did go one step further and make the SSLContext object static and rebuilt to test. If left hanging around then the SSL sessions are resumed and the full-deal handshake is no longer performed before each operation and everything behaves much more pleasant.

But again, not being an expert, this change may have consequences i am not thinking of.

Let me know what you think.

Thanks!
Ben

Hello Ben,

Thank you for sharing your concern. However, with HTTP the [ssl]socket is reused for each subsequent HTTP request, so I do not think SSLContext is recreated for each request. Whether connection is persistent or not depends on HTTP Keep-Alive header value (and that depends on the server settings), so I think that SSLContext might be created a few times during SVN operation like update or getDir, but it should not happen for each HTTP request.

Do you experience different behavior?

Thanks!

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

Hello Ben,

Thank you for sharing your concern. However, with HTTP the [ssl]socket is reused for each subsequent HTTP request, so I do not think SSLContext is recreated for each request. Whether connection is persistent or not depends on HTTP Keep-Alive header value (and that depends on the server settings), so I think that SSLContext might be created a few times during SVN operation like update or getDir, but it should not happen for each HTTP request.

Do you experience different behavior?

Thanks!

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

On Thu, Oct 8, 2015 at 1:31 AM, Ben Castellucci <[hidden email]> wrote:

Bump...

Any thoughts about making a change like this?

On Sep 30, 2015 10:46 AM, "Ben Castellucci" <[hidden email]> wrote:

Greetings.

This may indeed be the wrong place to bring this up. If so, could someone kindly direct me to the right place (be that a feature request or issue or whatever)?

Also, I will disclose I am not an expert in any way regarding how Java handles SSL communication so I may be completely off base here.

However, I was perusing the source and noticed in SVNSocketFactory.java, method createSSLContext(), it looks like a brand new SSLContext object is created every time. This ends up that the entire SSL handshake must be repeated for each and every SVN operation because the built in support for session resume is not able to function.

If the SSLContext object were stored in some way, possibly a static variable or something, that should allow SSL session resume which would avoid this issue.

I realize this would have no benefit for command line as it's a new JVM each time, however it would benefit GUI clients immensely. It would greatly speed up operations and make using SVN over SSL orders of magnitude more pleasant.

Let me know any thoughts.

Thanks!
Ben


Reply | Threaded
Open this post in threaded view
|

Re: SSL Session Resume?

Alexander Kitaev-4
Hello Ben,

Thank you for more detailed description of what you expect to happen. What you describe is currently expected behaviour.

For instance, when repository tree is browsed, "getDir" is called to expand each folder and that is a single low-level operation that includes several HTTP request. Connection is created for that operation and then disposed along with the SSLContext object. Same with other examples you've provided - single low-level operation, single persistent connection (with multiple requests being sent) and single SSLContext.

What I was saying is that within that low-level operation SSLContext should persist, but now I see your point - SSLConext indeed never outlives the socket/connection. Actually it never appeared to me that this would be correct to reuse already created SSLContext object to create more than a single socket. I'm not an expert on that either.

We'll check documentation on that to see the way SSLContext might be cached and reused. 

I've create an issue for that https://issues.tmatesoft.com/issue/SVNKIT-628 and I we could add SSLContext reuse as an optional feature first.

Thanks,
Alexander Kitaev.

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

On Tue, Oct 13, 2015 at 5:15 PM, Ben Castellucci <[hidden email]> wrote:

Thanks Alexander.

This is why i stated up front i am not an expert.

:)

However, i did take a little time to try and prove my theory. I grabbed the latest SVNKit source, built it and installed the plugin in Eclipse (coupled with Subclipse) then proceeded to debug it. Everytime i looked at the SSLSession object gleaned from the SSLSocket object in HTTPConnection class, method request(), it's isSessionResumption member is always false, always.

Further, here are some examples of behavior i see:

  1. When going to SVN Repository Exploring perspective in Eclipse and simply navigating the tree structure, the full-deal SSL handshake is performed every time i expand a folder.

  2. When shift-clicking and checking out multiple projects, the full-deal SSL handshake is performed prior to checking out each one.

  3. (This is one of the most painful) when reverting local changes, the full-deal SSL handshake is performed for EACH file being reverted.

These are just a few examples.

From what you say below and what i have experienced, most likely some of this is coming from the Subclipse plugin and how it is utilizing the SVNKit libraries. Maybe it's throwing away things and starting fresh when it shouldn't.

However, i did go one step further and make the SSLContext object static and rebuilt to test. If left hanging around then the SSL sessions are resumed and the full-deal handshake is no longer performed before each operation and everything behaves much more pleasant.

But again, not being an expert, this change may have consequences i am not thinking of.

Let me know what you think.

Thanks!
Ben

Hello Ben,

Thank you for sharing your concern. However, with HTTP the [ssl]socket is reused for each subsequent HTTP request, so I do not think SSLContext is recreated for each request. Whether connection is persistent or not depends on HTTP Keep-Alive header value (and that depends on the server settings), so I think that SSLContext might be created a few times during SVN operation like update or getDir, but it should not happen for each HTTP request.

Do you experience different behavior?

Thanks!

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

Hello Ben,

Thank you for sharing your concern. However, with HTTP the [ssl]socket is reused for each subsequent HTTP request, so I do not think SSLContext is recreated for each request. Whether connection is persistent or not depends on HTTP Keep-Alive header value (and that depends on the server settings), so I think that SSLContext might be created a few times during SVN operation like update or getDir, but it should not happen for each HTTP request.

Do you experience different behavior?

Thanks!

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

On Thu, Oct 8, 2015 at 1:31 AM, Ben Castellucci <[hidden email]> wrote:

Bump...

Any thoughts about making a change like this?

On Sep 30, 2015 10:46 AM, "Ben Castellucci" <[hidden email]> wrote:

Greetings.

This may indeed be the wrong place to bring this up. If so, could someone kindly direct me to the right place (be that a feature request or issue or whatever)?

Also, I will disclose I am not an expert in any way regarding how Java handles SSL communication so I may be completely off base here.

However, I was perusing the source and noticed in SVNSocketFactory.java, method createSSLContext(), it looks like a brand new SSLContext object is created every time. This ends up that the entire SSL handshake must be repeated for each and every SVN operation because the built in support for session resume is not able to function.

If the SSLContext object were stored in some way, possibly a static variable or something, that should allow SSL session resume which would avoid this issue.

I realize this would have no benefit for command line as it's a new JVM each time, however it would benefit GUI clients immensely. It would greatly speed up operations and make using SVN over SSL orders of magnitude more pleasant.

Let me know any thoughts.

Thanks!
Ben



Reply | Threaded
Open this post in threaded view
|

Re: SSL Session Resume?

Ben Castellucci

Thanks Alexander!

Much appreciated!

Ben

On Oct 13, 2015 11:52 AM, "Alexander Kitaev" <[hidden email]> wrote:
Hello Ben,

Thank you for more detailed description of what you expect to happen. What you describe is currently expected behaviour.

For instance, when repository tree is browsed, "getDir" is called to expand each folder and that is a single low-level operation that includes several HTTP request. Connection is created for that operation and then disposed along with the SSLContext object. Same with other examples you've provided - single low-level operation, single persistent connection (with multiple requests being sent) and single SSLContext.

What I was saying is that within that low-level operation SSLContext should persist, but now I see your point - SSLConext indeed never outlives the socket/connection. Actually it never appeared to me that this would be correct to reuse already created SSLContext object to create more than a single socket. I'm not an expert on that either.

We'll check documentation on that to see the way SSLContext might be cached and reused. 

I've create an issue for that https://issues.tmatesoft.com/issue/SVNKIT-628 and I we could add SSLContext reuse as an optional feature first.

Thanks,
Alexander Kitaev.

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

On Tue, Oct 13, 2015 at 5:15 PM, Ben Castellucci <[hidden email]> wrote:

Thanks Alexander.

This is why i stated up front i am not an expert.

:)

However, i did take a little time to try and prove my theory. I grabbed the latest SVNKit source, built it and installed the plugin in Eclipse (coupled with Subclipse) then proceeded to debug it. Everytime i looked at the SSLSession object gleaned from the SSLSocket object in HTTPConnection class, method request(), it's isSessionResumption member is always false, always.

Further, here are some examples of behavior i see:

  1. When going to SVN Repository Exploring perspective in Eclipse and simply navigating the tree structure, the full-deal SSL handshake is performed every time i expand a folder.

  2. When shift-clicking and checking out multiple projects, the full-deal SSL handshake is performed prior to checking out each one.

  3. (This is one of the most painful) when reverting local changes, the full-deal SSL handshake is performed for EACH file being reverted.

These are just a few examples.

From what you say below and what i have experienced, most likely some of this is coming from the Subclipse plugin and how it is utilizing the SVNKit libraries. Maybe it's throwing away things and starting fresh when it shouldn't.

However, i did go one step further and make the SSLContext object static and rebuilt to test. If left hanging around then the SSL sessions are resumed and the full-deal handshake is no longer performed before each operation and everything behaves much more pleasant.

But again, not being an expert, this change may have consequences i am not thinking of.

Let me know what you think.

Thanks!
Ben

Hello Ben,

Thank you for sharing your concern. However, with HTTP the [ssl]socket is reused for each subsequent HTTP request, so I do not think SSLContext is recreated for each request. Whether connection is persistent or not depends on HTTP Keep-Alive header value (and that depends on the server settings), so I think that SSLContext might be created a few times during SVN operation like update or getDir, but it should not happen for each HTTP request.

Do you experience different behavior?

Thanks!

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

Hello Ben,

Thank you for sharing your concern. However, with HTTP the [ssl]socket is reused for each subsequent HTTP request, so I do not think SSLContext is recreated for each request. Whether connection is persistent or not depends on HTTP Keep-Alive header value (and that depends on the server settings), so I think that SSLContext might be created a few times during SVN operation like update or getDir, but it should not happen for each HTTP request.

Do you experience different behavior?

Thanks!

Alexander Kitaev,
TMate Software,
http://subgit.com/ - Svn to Git Migration!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

On Thu, Oct 8, 2015 at 1:31 AM, Ben Castellucci <[hidden email]> wrote:

Bump...

Any thoughts about making a change like this?

On Sep 30, 2015 10:46 AM, "Ben Castellucci" <[hidden email]> wrote:

Greetings.

This may indeed be the wrong place to bring this up. If so, could someone kindly direct me to the right place (be that a feature request or issue or whatever)?

Also, I will disclose I am not an expert in any way regarding how Java handles SSL communication so I may be completely off base here.

However, I was perusing the source and noticed in SVNSocketFactory.java, method createSSLContext(), it looks like a brand new SSLContext object is created every time. This ends up that the entire SSL handshake must be repeated for each and every SVN operation because the built in support for session resume is not able to function.

If the SSLContext object were stored in some way, possibly a static variable or something, that should allow SSL session resume which would avoid this issue.

I realize this would have no benefit for command line as it's a new JVM each time, however it would benefit GUI clients immensely. It would greatly speed up operations and make using SVN over SSL orders of magnitude more pleasant.

Let me know any thoughts.

Thanks!
Ben