You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Vincent Goelen <go...@gmail.com> on 2012/11/28 09:14:03 UTC
Tomcat 7 SSL Session ID
Hey,
I'm doing some research about the SSL session tracking / SSL Session id's.
Now I'm having some problems when requests are send to the server in quick
succession, I notice the problem is fixed or at least less occuring when
the keepAlive server setting is set to 0..
When the keepAliveTimeout is not set to "0" I can see in the SSL debug logs
the SSL session get's invalidated after some requests with a Broken Pipe
exception. Is this because there are too many open connections during
the keepAliveTimeout?
It also only happens when processing the requests takes some time (fe.
storing items in database) or when I put the threat to sleep for testing
purpose.
When inspecting the traffic I see some tcp-rst packages (problem is here?)
from previous connections while the current one is being processed.
My question is why these SSL Sessions get invalidated after alot of quick
requests to the server since this gives a problem with my SSL Session
tracking since the id changes then.
I can provide a sample jsp project where the Invalidation occurs if wanted..
PS. I'm running Tomcat 7 on a mac osx Lion 10.7.4
server.xml settings:
<Connector
port="8443" maxHttpHeaderSize="8192"
maxThreads="150"
keepAliveTimeout="0"
scheme="https" secure="true"
clientAuth="false"
sslProtocol="SSLv3"
SSLEngine="on"
SSLEnabled="true"
ciphers = "TLS_RSA_WITH_AES_256_CBC_SHA"
SSLCipherSuite ="TTLS_RSA_WITH_AES_256_CBC_SHA"
SSLHonorCipherOrder = "true"
keystoreFile="***" keystorePass="***"/>
Thanks in advance,
Vincent Goelen
RE: Tomcat 7 SSL Session ID
Posted by Esmond Pitt <es...@bigpond.com>.
The peer can't receive the SSL close_notify or the TCP FIN until it has
received all the pending data from the sender. Conversely, if there is any
TCP data in flight back to the sender when the peer receives the
close_notify and FIN it will not be discarded. The response close_notify and
FIN can only be sent after any pending data.
EJP
-----Original Message-----
From: Vincent Goelen [mailto:goelenv@gmail.com]
Sent: Tuesday, 18 December 2012 3:52 AM
To: Tomcat Users List
Subject: Re: Tomcat 7 SSL Session ID
If you run the test.jsp page.. When you send a request and interrupt it
while it's processing.. For example by pressing the stop loading button
immediatly after sending the request or by pressing the refresh button fast
enough..
When you look what happens then: the SSL connection sends close notifies
which should make sure no more data is sent over the connection..
This does happen, the client has sent it's TCP close packet and after that
it receives application data from the server while it shouldn't do that
according to the ssl specs.. When the client receives this application data
after the connection is already closed, it sends a TCP rst packet causing an
invalidate of the server...
This problem has nothing to do with not using the exception handling but
seems to me more a problem of Tomcat's priority of TCP specs in front of SSL
specs
2012/12/17 Martin Gainty <mg...@hotmail.com>
>
> Session.SessionTrackingModelListener.java contains
> context.setSessionTrackingModes(modes); with no exception handling /**
> * @param sessionTrackingModes
> * @throws IllegalArgumentException
> * If sessionTrackingModes specifies
> * {@link SessionTrackingMode#SSL} in combination with any
> other
> * {@link SessionTrackingMode}
> * @throws IllegalStateException
> * If the context has already been initialised
> * @throws UnsupportedOperationException
> * @since Servlet 3.0 TODO SERVLET3 - Add comments
> */
>
> public void setSessionTrackingModes(Set<SessionTrackingMode>
> sessionTrackingModes) throws IllegalStateException,
> IllegalArgumentException; Moral of the story..always catch declared
> Exceptions where is the jsp you test with?
> Martin
> ______________________________________________ Please do not alter or
> otherwise disrupt this communication..thank you > Date: Mon, 17 Dec
> 2012 09:47:09 +0100
> > Subject: Re: Tomcat 7 SSL Session ID
> > From: goelenv@gmail.com
> > To: users@tomcat.apache.org
> >
> > Hey,
> >
> > http://users.telenet.be/goelenv/SSLTomcat.zip
> >
> > in this link you can find a netbeans project that will generate the
> fault..
> > The index.html page will send requests to the index.jsp page, the
> > thread sleep is just to emulate a long process of a request (like
> > database
> things,
> > etc)
> >
> > Kind regards,
> > Vincent
> >
> > 2012/12/10 Christopher Schultz <ch...@christopherschultz.net>
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > >
> > > Martin,
> > >
> > > On 12/10/12 10:22 AM, Martin Gainty wrote:
> > > > we need to get your architect into this discussion
> > > >
> > > > Why is your code implementing 2 different Connections to
> > > > accomplish this functionality when one Connection at a time will
> > > > suffice?
> > >
> > > You have no idea what you are talking about. There is only one
> > > connection. There is only one connector. The OP is reporting that
> > > his SSL session id expires long before he is expecting it to expire.
> > >
> > > This has nothing to do with webapps and connectors except he
> > > happens to have a connector and a webapp.
> > >
> > > - -chris
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> > > Comment: GPGTools - http://gpgtools.org
> > > Comment: Using GnuPG with undefined - http://www.enigmail.net/
> > >
> > > iEYEAREIAAYFAlDGXhIACgkQ9CaO5/Lv0PDwtQCgk63c5ZUVojVhdgVpHpF5IMkX
> > > 3lYAoKPCpNeo8lEquukN/BRxPjuFfl1E
> > > =tdIg
> > > -----END PGP SIGNATURE-----
> > >
> > > ------------------------------------------------------------------
> > > --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 SSL Session ID
Posted by Vincent Goelen <go...@gmail.com>.
If you run the test.jsp page.. When you send a request and interrupt it
while it's processing.. For example by pressing the stop loading button
immediatly after sending the request or by pressing the refresh button fast
enough..
When you look what happens then: the SSL connection sends close notifies
which should make sure no more data is sent over the connection..
This does happen, the client has sent it's TCP close packet and after that
it receives application data from the server while it shouldn't do that
according to the ssl specs.. When the client receives this application data
after the connection is already closed, it sends a TCP rst packet causing
an invalidate of the server...
This problem has nothing to do with not using the exception handling but
seems to me more a problem of Tomcat's priority of TCP specs in front of
SSL specs
2012/12/17 Martin Gainty <mg...@hotmail.com>
>
> Session.SessionTrackingModelListener.java contains
> context.setSessionTrackingModes(modes); with no exception handling /**
> * @param sessionTrackingModes
> * @throws IllegalArgumentException
> * If sessionTrackingModes specifies
> * {@link SessionTrackingMode#SSL} in combination with any
> other
> * {@link SessionTrackingMode}
> * @throws IllegalStateException
> * If the context has already been initialised
> * @throws UnsupportedOperationException
> * @since Servlet 3.0 TODO SERVLET3 - Add comments
> */
>
> public void setSessionTrackingModes(Set<SessionTrackingMode>
> sessionTrackingModes) throws IllegalStateException,
> IllegalArgumentException;
> Moral of the story..always catch declared Exceptions
> where is the jsp you test with?
> Martin
> ______________________________________________ Please do not alter or
> otherwise disrupt this communication..thank you
> > Date: Mon, 17 Dec 2012 09:47:09 +0100
> > Subject: Re: Tomcat 7 SSL Session ID
> > From: goelenv@gmail.com
> > To: users@tomcat.apache.org
> >
> > Hey,
> >
> > http://users.telenet.be/goelenv/SSLTomcat.zip
> >
> > in this link you can find a netbeans project that will generate the
> fault..
> > The index.html page will send requests to the index.jsp page, the thread
> > sleep is just to emulate a long process of a request (like database
> things,
> > etc)
> >
> > Kind regards,
> > Vincent
> >
> > 2012/12/10 Christopher Schultz <ch...@christopherschultz.net>
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > >
> > > Martin,
> > >
> > > On 12/10/12 10:22 AM, Martin Gainty wrote:
> > > > we need to get your architect into this discussion
> > > >
> > > > Why is your code implementing 2 different Connections to
> > > > accomplish this functionality when one Connection at a time will
> > > > suffice?
> > >
> > > You have no idea what you are talking about. There is only one
> > > connection. There is only one connector. The OP is reporting that his
> > > SSL session id expires long before he is expecting it to expire.
> > >
> > > This has nothing to do with webapps and connectors except he happens
> > > to have a connector and a webapp.
> > >
> > > - -chris
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> > > Comment: GPGTools - http://gpgtools.org
> > > Comment: Using GnuPG with undefined - http://www.enigmail.net/
> > >
> > > iEYEAREIAAYFAlDGXhIACgkQ9CaO5/Lv0PDwtQCgk63c5ZUVojVhdgVpHpF5IMkX
> > > 3lYAoKPCpNeo8lEquukN/BRxPjuFfl1E
> > > =tdIg
> > > -----END PGP SIGNATURE-----
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
>
>
RE: Tomcat 7 SSL Session ID
Posted by Martin Gainty <mg...@hotmail.com>.
Session.SessionTrackingModelListener.java contains
context.setSessionTrackingModes(modes); with no exception handling /**
* @param sessionTrackingModes
* @throws IllegalArgumentException
* If sessionTrackingModes specifies
* {@link SessionTrackingMode#SSL} in combination with any other
* {@link SessionTrackingMode}
* @throws IllegalStateException
* If the context has already been initialised
* @throws UnsupportedOperationException
* @since Servlet 3.0 TODO SERVLET3 - Add comments
*/
public void setSessionTrackingModes(Set<SessionTrackingMode> sessionTrackingModes) throws IllegalStateException, IllegalArgumentException;
Moral of the story..always catch declared Exceptions
where is the jsp you test with?
Martin
______________________________________________ Please do not alter or otherwise disrupt this communication..thank you
> Date: Mon, 17 Dec 2012 09:47:09 +0100
> Subject: Re: Tomcat 7 SSL Session ID
> From: goelenv@gmail.com
> To: users@tomcat.apache.org
>
> Hey,
>
> http://users.telenet.be/goelenv/SSLTomcat.zip
>
> in this link you can find a netbeans project that will generate the fault..
> The index.html page will send requests to the index.jsp page, the thread
> sleep is just to emulate a long process of a request (like database things,
> etc)
>
> Kind regards,
> Vincent
>
> 2012/12/10 Christopher Schultz <ch...@christopherschultz.net>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Martin,
> >
> > On 12/10/12 10:22 AM, Martin Gainty wrote:
> > > we need to get your architect into this discussion
> > >
> > > Why is your code implementing 2 different Connections to
> > > accomplish this functionality when one Connection at a time will
> > > suffice?
> >
> > You have no idea what you are talking about. There is only one
> > connection. There is only one connector. The OP is reporting that his
> > SSL session id expires long before he is expecting it to expire.
> >
> > This has nothing to do with webapps and connectors except he happens
> > to have a connector and a webapp.
> >
> > - -chris
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> > Comment: GPGTools - http://gpgtools.org
> > Comment: Using GnuPG with undefined - http://www.enigmail.net/
> >
> > iEYEAREIAAYFAlDGXhIACgkQ9CaO5/Lv0PDwtQCgk63c5ZUVojVhdgVpHpF5IMkX
> > 3lYAoKPCpNeo8lEquukN/BRxPjuFfl1E
> > =tdIg
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
Re: Tomcat 7 SSL Session ID
Posted by Vincent Goelen <go...@gmail.com>.
Hey,
http://users.telenet.be/goelenv/SSLTomcat.zip
in this link you can find a netbeans project that will generate the fault..
The index.html page will send requests to the index.jsp page, the thread
sleep is just to emulate a long process of a request (like database things,
etc)
Kind regards,
Vincent
2012/12/10 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Martin,
>
> On 12/10/12 10:22 AM, Martin Gainty wrote:
> > we need to get your architect into this discussion
> >
> > Why is your code implementing 2 different Connections to
> > accomplish this functionality when one Connection at a time will
> > suffice?
>
> You have no idea what you are talking about. There is only one
> connection. There is only one connector. The OP is reporting that his
> SSL session id expires long before he is expecting it to expire.
>
> This has nothing to do with webapps and connectors except he happens
> to have a connector and a webapp.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEAREIAAYFAlDGXhIACgkQ9CaO5/Lv0PDwtQCgk63c5ZUVojVhdgVpHpF5IMkX
> 3lYAoKPCpNeo8lEquukN/BRxPjuFfl1E
> =tdIg
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat 7 SSL Session ID
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Martin,
On 12/10/12 10:22 AM, Martin Gainty wrote:
> we need to get your architect into this discussion
>
> Why is your code implementing 2 different Connections to
> accomplish this functionality when one Connection at a time will
> suffice?
You have no idea what you are talking about. There is only one
connection. There is only one connector. The OP is reporting that his
SSL session id expires long before he is expecting it to expire.
This has nothing to do with webapps and connectors except he happens
to have a connector and a webapp.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEAREIAAYFAlDGXhIACgkQ9CaO5/Lv0PDwtQCgk63c5ZUVojVhdgVpHpF5IMkX
3lYAoKPCpNeo8lEquukN/BRxPjuFfl1E
=tdIg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 7 SSL Session ID
Posted by Martin Gainty <mg...@hotmail.com>.
we need to get your architect into this discussion
Why is your code implementing 2 different Connections to accomplish this functionality when one Connection at a time will suffice? Martin ______________________________________________
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Date: Mon, 10 Dec 2012 14:48:30 +0100
> Subject: Re: Tomcat 7 SSL Session ID
> From: goelenv@gmail.com
> To: users@tomcat.apache.org
>
> There are no 2 different webapps to be clear.. It's one app that gives
> problems when there are parallel connections with the same client..
>
> 2012/12/6 Martin Gainty <mg...@hotmail.com>
>
> >
> > can you split the 2 webapps to run on 2 completely different Tomcat
> > instances running on 2 completely different <Connection> configured in
> > server.xml The connection causing the TCP RST is on one tomcat instance and
> > doesnt enable or use the other connections (and does not cause a Session
> > Invalidate) as SSLConnection is disable
> >
> > the second webapp enables the SSLConnection and does not interact with any
> > other TCP connections as any other TCP or HTTP connections are not enabled
> > in the second TC instance
> > if you run the simple curl script implementing the keys, password and
> > CACert do you see a key exchange?
> > (that is the behaviour you want to emulate in your Servlet code)
> > Martin
> > ______________________________________________
> > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
> >
> > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> > dient lediglich dem Austausch von Informationen und entfaltet keine
> > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> > destinataire prévu, nous te demandons avec bonté que pour satisfaire
> > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
> > de ceci est interdite. Ce message sert à l'information seulement et n'aura
> > pas n'importe quel effet légalement obligatoire. Étant donné que les email
> > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
> > aucune responsabilité pour le contenu fourni.
> >
> > > Date: Thu, 6 Dec 2012 11:12:26 +0100
> > > Subject: Re: Tomcat 7 SSL Session ID
> > > From: goelenv@gmail.com
> > > To: users@tomcat.apache.org
> > >
> > > Hey,
> > > I'm completely aware that a RST always terminates a TCP connections..
> > > But in my case, there's an TCP rst from a connection thats already
> > finished
> > > it's job causing problems for the active connection! At least that's
> > what I
> > > think is going on here..
> > > As you can see in the screenshot of my wireshark capture, the TCP rst
> > there
> > > is not from the connection that's writing application data..
> > >
> > > The session get's invalidates here because of an unexpected close of the
> > > connection which is completely normal regarding the SSL specs.
> > >
> > > grts,
> > > Vincent
> > >
> > > 2012/12/5 Esmond Pitt <es...@bigpond.com>
> > >
> > > > Vincent
> > > >
> > > > RST always terminates a TCP connection. The question is really why was
> > it
> > > > *sent.* The usual reason is writing to a connection that has already
> > been
> > > > closed by the peer. Is there an incoming close_notify higher up in the
> > SSL
> > > > log? I suppose not otherwise an SSLException would have been thrown.
> > > >
> > > > Re loss of the SSL session, I suppose it is plausible that SSL
> > discards it
> > > > on security grounds because of the broken connection.
> > > >
> > > > EJP
> > > >
> > > > _____
> > > >
> > > > From: Vincent Goelen [mailto:goelenv@gmail.com]
> > > > Sent: Wednesday, 5 December 2012 9:19 PM
> > > > To: Esmond Pitt
> > > > Subject: Re: Tomcat 7 SSL Session ID
> > > >
> > > >
> > > >
> > > > http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 32
> > > > http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 432
> > > > http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 32
> > > > http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 976
> > > > http-bio-8443-exec-20, handling exception: java.net.SocketException:
> > Broken
> > > > pipe
> > > > %% Invalidated: [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA]
> > > > http-bio-8443-exec-20, SEND TLSv1 ALERT: fatal, description =
> > > > unexpected_message
> > > > http-bio-8443-exec-20, WRITE: TLSv1 Alert, length = 32
> > > > http-bio-8443-exec-20, Exception sending alert:
> > java.net.SocketException:
> > > > Broken pipe
> > > > http-bio-8443-exec-20, called closeSocket()
> > > > http-bio-8443-exec-20, called close()
> > > > http-bio-8443-exec-20, called closeInternal(true)
> > > >
> > > >
> > > > This is what I get in the SSL debug logs.. It seems to happen when the
> > tcp
> > > > connection is closed while the application data is being sent.. I think
> > > > this
> > > > is a security thing to prevent SSL truncation attacks which sounds
> > quite
> > > > normal to me.
> > > >
> > > > The issue is, why does my tcp connection close there:
> > > >
> > > >
> > http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.5
> > > > 6.png<
> > http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.56.png
> > >
> > > >
> > > > The screenshot above is one from where things go wrong when I analyse
> > the
> > > > traffic, the tcp rst is one from the connection that was used by the
> > > > previous request.. But why can that rst packet terminate the current
> > active
> > > > tcp connection?
> > > >
> > > >
> > > > 2012/12/5 Esmond Pitt <es...@bigpond.com>
> > > >
> > > >
> > > > Yes but he *already has* an SSL session which he states is being
> > > > invalidated. To the limited extent to which I could make sense of your
> > > > incomprehensible post, it appears to be 100% irrelevant.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Martin Gainty [mailto:mgainty@hotmail.com]
> > > > Sent: Wednesday, 5 December 2012 11:27 AM
> > > > To: Tomcat Users List; goelenv@gmail.com
> > > > Subject: RE: Tomcat 7 SSL Session ID
> > > >
> > > >
> > > >
> > > > yes but he needs to achieve a reliable connection between himself and
> > the
> > > > SSLServer (at least until key negotiation has completed) broken
> > pipe(s) are
> > > > a bear to debug but you have a few tools available to you:
> > > >
> > > > netstat SSLServerIP
> > > > -- if you see ANY intervening nodes hanging more than 4 sec drop from
> > arp
> > > > cache generally by arp -d ServerIP
> > > > assuming your ServerIP is is 157.55.85.212 and the physical address of
> > the
> > > > network you want to connect to is 00-aa-00-62-c6-09 (check with
> > net-admin
> > > > for the physical-address or eth-addr to use) > arp -s 157.55.85.212
> > > > 00-aa-00-62-c6-09 .... Adds a static entry.
> > > > > arp -a .... Displays the arp
> > table.
> > > > route print will display the routes between you and the SSLServer if
> > you
> > > > dont see a route referencing the server you may want to add in your own
> > > > route with
> > > > route add DESTINATION MASK Mask METRIC NoOfHops Interface
> > > >
> > > > InterfaceNumbercheck with net-admin DESTINATION is generally the
> > > > dotted.quad.of.SSLServercheck with net-admin generally Mask
> > =255.255.255.0
> > > > will docheck with net admin about which Interface to use..avoid
> > 127.0.0.1
> > > > (unless testing locally)check with net admin on NoOfHops param
> > ..generally
> > > >
> > > > the lower the better use curl (command line url) to check the validity
> > of
> > > >
> > > > the certificate, keys and passwordscurl -1 --cacert [file] --key
> > > >
> > > > PrivateKey.jks --pass PrivateKeyPass --key-type PEM --pubkey
> > > > PublicKey.jks-1
> > > >
> > > > says use TLSv1check the type of key most keys start out as PEM PEM key
> > ends
> > > >
> > > > with .PEM extension ...DER key with .DER... ENG key ends with
> > > >
> > > > .ENGhttp://curl.haxx.se/docs/sslcerts.html once you've been able to
> > > > achieve
> > > >
> > > > a Key Exchange you will have a valid SSL Connection..remember binaries
> > have
> > > > lower CPU so test with a reliable binary first then start debugging
> > your
> > > > code (i assume you added your CA cert into your local truststore)
> > enough
> > > > pollution?
> > > > Martin
> > > > ______________________________________________
> > > > Verzicht und Vertraulichkeitanmerkung
> > > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> > > > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> > unbefugte
> > > > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese
> > Nachricht
> > > > dient lediglich dem Austausch von Informationen und entfaltet keine
> > > > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> > > > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> > > >
> > > >
> > > > > From: esmond.pitt@bigpond.com
> > > > > To: goelenv@gmail.com; users@tomcat.apache.org
> > > > > Subject: RE: Tomcat 7 SSL Session ID
> > > > > Date: Wed, 5 Dec 2012 09:57:38 +1100
> > > > >
> > > > > Broken pipes don't invalidate the SSL session. They just break the
> > TCP
> > > > > connection. The SSL session persists, across multiple TCP
> > connections,
> > > > > until it is specifically invalidated by someone: for example, timed
> > > > > out by the SSLSessionContext.
> > > > >
> > > > > EJP
> > > > >
> > > > > _____
> > > > >
> > > > > From: Vincent Goelen [mailto:goelenv@gmail.com]
> > > > > Sent: Wednesday, 5 December 2012 1:15 AM
> > > > > To: Tomcat Users List
> > > > > Subject: Re: Tomcat 7 SSL Session ID
> > > > >
> > > > >
> > > > > Hey,
> > > > >
> > > > > thanks for the help!
> > > > >
> > > > > To be clear, I do not want a 0ms timeout... I'm doing research about
> > > > > how "usable" the SSL session tracking option is for session
> > management...
> > > > > With the standard settings it seems very unstable to me, when sending
> > > > > alot of parallel requests I get a broken socket error invalidating
> > the
> > > > > ssl session and making the session with this id disappear. In this
> > > > > case it would seem to me that it's easy to create Denial of Service
> > > > > attacks by just sending alot of requests so the user loses his
> > session.
> > > > >
> > > > > By playing with the timeouts I found out this problem doesn't occur
> > > > > when I set the timeout to 0, just by playing with the settings.
> > > > > Perhaps because this disables the possibility of too many parallel
> > > > > connections? I can't find the reason of this in the Tomcat or SSL
> > > > specs...
> > > > >
> > > > > I've added a screenshot of a capture where things go wrong without
> > > > > setting a keepAlive.. So I send alot of requests to the server, the
> > > > > first clientHello (pck 38943) and the following packets everything
> > > > > goes ok, when the application data is being send I get a tcp rst from
> > > > > port 54195 (this is the connection that was used for the transactions
> > > > > before the current one) ... At this moment my session gets
> > invalidates
> > > > > making the next SSL handshake a full one with new ID (pckt 40361,
> > ...)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2012/11/29 Christopher Schultz <ch...@christopherschultz.net>
> > > > >
> > > > >
> > > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > > Hash: SHA1
> > > > >
> > > > > Vincent,
> > > > >
> > > > >
> > > > > On 11/28/12 3:14 AM, Vincent Goelen wrote:
> > > > > > When the keepAliveTimeout is not set to "0" I can see in the SSL
> > > > > > debug logs the SSL session get's invalidated after some requests
> > > > > > with a Broken Pipe exception. Is this because there are too many
> > > > > > open connections during the keepAliveTimeout?
> > > > >
> > > > >
> > > > > It's probably because of your pathological keepAliveTimeout. 0ms
> > > > > seems, er, low. Why did you choose 0ms?
> > > > >
> > > > > I haven't looked at the code, so I'm not sure if the elapsed timer
> > > > > starts when the last request is completed (which seems reasonable) or
> > > > > when the last request started. I suspect the latter. 0ms is awfully
> > > > > short. Are you sure that your client is capable of accepting the
> > > > > response to the previous request and turn-around and make another
> > > > > request across the same channel before 0ms passes?
> > > > >
> > > > >
> > > > > > It also only happens when processing the requests takes some time
> > > > > > (fe. storing items in database) or when I put the threat to sleep
> > > > > > for testing purpose.
> > > > >
> > > > >
> > > > > So if you have a trivial request (say, HEAD for a static resource),
> > > > > you can never get a failure?
> > > > >
> > > > >
> > > > > > When inspecting the traffic I see some tcp-rst packages (problem is
> > > > > > here?) from previous connections while the current one is being
> > > > > > processed.
> > > > >
> > > > >
> > > > > When you say "current one" what do you mean? If you are using a
> > single
> > > > > connection with HTTP keepalive, then there is only one connection to
> > > > > talk about: you can't get RSTs from "previous connections". You may
> > be
> > > > > getting TCP RST as the server closes the connection while the client
> > > > > is trying to write. Is that what you are experiencing?
> > > > >
> > > > >
> > > > > > My question is why these SSL Sessions get invalidated after alot of
> > > > > > quick requests to the server since this gives a problem with my SSL
> > > > > > Session tracking since the id changes then.
> > > > >
> > > > >
> > > > > Maybe if you can explain why you want a 0ms keepalive timeout it
> > would
> > > > > be helpful. If you want to disable keep alives, set
> > > > > maxKeepAliveRequests="1". If you want to allow an infinite timeout,
> > > > > try using keepAliveTimeout="-1" as the documentation states.
> > > > >
> > > > > - -chris
> > > > > -----BEGIN PGP SIGNATURE-----
> > > > > Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> > > > > Comment: GPGTools - http://gpgtools.org
> > > > > Comment: Using GnuPG with undefined - http://www.enigmail.net/
> > > > >
> > > > > iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI
> > > > > tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF
> > > > > =J7dz
> > > > > -----END PGP SIGNATURE-----
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > > For additional commands, e-mail: users-help@tomcat.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
Re: Tomcat 7 SSL Session ID
Posted by Vincent Goelen <go...@gmail.com>.
There are no 2 different webapps to be clear.. It's one app that gives
problems when there are parallel connections with the same client..
2012/12/6 Martin Gainty <mg...@hotmail.com>
>
> can you split the 2 webapps to run on 2 completely different Tomcat
> instances running on 2 completely different <Connection> configured in
> server.xml The connection causing the TCP RST is on one tomcat instance and
> doesnt enable or use the other connections (and does not cause a Session
> Invalidate) as SSLConnection is disable
>
> the second webapp enables the SSLConnection and does not interact with any
> other TCP connections as any other TCP or HTTP connections are not enabled
> in the second TC instance
> if you run the simple curl script implementing the keys, password and
> CACert do you see a key exchange?
> (that is the behaviour you want to emulate in your Servlet code)
> Martin
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
> de ceci est interdite. Ce message sert à l'information seulement et n'aura
> pas n'importe quel effet légalement obligatoire. Étant donné que les email
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
> aucune responsabilité pour le contenu fourni.
>
> > Date: Thu, 6 Dec 2012 11:12:26 +0100
> > Subject: Re: Tomcat 7 SSL Session ID
> > From: goelenv@gmail.com
> > To: users@tomcat.apache.org
> >
> > Hey,
> > I'm completely aware that a RST always terminates a TCP connections..
> > But in my case, there's an TCP rst from a connection thats already
> finished
> > it's job causing problems for the active connection! At least that's
> what I
> > think is going on here..
> > As you can see in the screenshot of my wireshark capture, the TCP rst
> there
> > is not from the connection that's writing application data..
> >
> > The session get's invalidates here because of an unexpected close of the
> > connection which is completely normal regarding the SSL specs.
> >
> > grts,
> > Vincent
> >
> > 2012/12/5 Esmond Pitt <es...@bigpond.com>
> >
> > > Vincent
> > >
> > > RST always terminates a TCP connection. The question is really why was
> it
> > > *sent.* The usual reason is writing to a connection that has already
> been
> > > closed by the peer. Is there an incoming close_notify higher up in the
> SSL
> > > log? I suppose not otherwise an SSLException would have been thrown.
> > >
> > > Re loss of the SSL session, I suppose it is plausible that SSL
> discards it
> > > on security grounds because of the broken connection.
> > >
> > > EJP
> > >
> > > _____
> > >
> > > From: Vincent Goelen [mailto:goelenv@gmail.com]
> > > Sent: Wednesday, 5 December 2012 9:19 PM
> > > To: Esmond Pitt
> > > Subject: Re: Tomcat 7 SSL Session ID
> > >
> > >
> > >
> > > http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 32
> > > http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 432
> > > http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 32
> > > http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 976
> > > http-bio-8443-exec-20, handling exception: java.net.SocketException:
> Broken
> > > pipe
> > > %% Invalidated: [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA]
> > > http-bio-8443-exec-20, SEND TLSv1 ALERT: fatal, description =
> > > unexpected_message
> > > http-bio-8443-exec-20, WRITE: TLSv1 Alert, length = 32
> > > http-bio-8443-exec-20, Exception sending alert:
> java.net.SocketException:
> > > Broken pipe
> > > http-bio-8443-exec-20, called closeSocket()
> > > http-bio-8443-exec-20, called close()
> > > http-bio-8443-exec-20, called closeInternal(true)
> > >
> > >
> > > This is what I get in the SSL debug logs.. It seems to happen when the
> tcp
> > > connection is closed while the application data is being sent.. I think
> > > this
> > > is a security thing to prevent SSL truncation attacks which sounds
> quite
> > > normal to me.
> > >
> > > The issue is, why does my tcp connection close there:
> > >
> > >
> http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.5
> > > 6.png<
> http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.56.png
> >
> > >
> > > The screenshot above is one from where things go wrong when I analyse
> the
> > > traffic, the tcp rst is one from the connection that was used by the
> > > previous request.. But why can that rst packet terminate the current
> active
> > > tcp connection?
> > >
> > >
> > > 2012/12/5 Esmond Pitt <es...@bigpond.com>
> > >
> > >
> > > Yes but he *already has* an SSL session which he states is being
> > > invalidated. To the limited extent to which I could make sense of your
> > > incomprehensible post, it appears to be 100% irrelevant.
> > >
> > >
> > > -----Original Message-----
> > > From: Martin Gainty [mailto:mgainty@hotmail.com]
> > > Sent: Wednesday, 5 December 2012 11:27 AM
> > > To: Tomcat Users List; goelenv@gmail.com
> > > Subject: RE: Tomcat 7 SSL Session ID
> > >
> > >
> > >
> > > yes but he needs to achieve a reliable connection between himself and
> the
> > > SSLServer (at least until key negotiation has completed) broken
> pipe(s) are
> > > a bear to debug but you have a few tools available to you:
> > >
> > > netstat SSLServerIP
> > > -- if you see ANY intervening nodes hanging more than 4 sec drop from
> arp
> > > cache generally by arp -d ServerIP
> > > assuming your ServerIP is is 157.55.85.212 and the physical address of
> the
> > > network you want to connect to is 00-aa-00-62-c6-09 (check with
> net-admin
> > > for the physical-address or eth-addr to use) > arp -s 157.55.85.212
> > > 00-aa-00-62-c6-09 .... Adds a static entry.
> > > > arp -a .... Displays the arp
> table.
> > > route print will display the routes between you and the SSLServer if
> you
> > > dont see a route referencing the server you may want to add in your own
> > > route with
> > > route add DESTINATION MASK Mask METRIC NoOfHops Interface
> > >
> > > InterfaceNumbercheck with net-admin DESTINATION is generally the
> > > dotted.quad.of.SSLServercheck with net-admin generally Mask
> =255.255.255.0
> > > will docheck with net admin about which Interface to use..avoid
> 127.0.0.1
> > > (unless testing locally)check with net admin on NoOfHops param
> ..generally
> > >
> > > the lower the better use curl (command line url) to check the validity
> of
> > >
> > > the certificate, keys and passwordscurl -1 --cacert [file] --key
> > >
> > > PrivateKey.jks --pass PrivateKeyPass --key-type PEM --pubkey
> > > PublicKey.jks-1
> > >
> > > says use TLSv1check the type of key most keys start out as PEM PEM key
> ends
> > >
> > > with .PEM extension ...DER key with .DER... ENG key ends with
> > >
> > > .ENGhttp://curl.haxx.se/docs/sslcerts.html once you've been able to
> > > achieve
> > >
> > > a Key Exchange you will have a valid SSL Connection..remember binaries
> have
> > > lower CPU so test with a reliable binary first then start debugging
> your
> > > code (i assume you added your CA cert into your local truststore)
> enough
> > > pollution?
> > > Martin
> > > ______________________________________________
> > > Verzicht und Vertraulichkeitanmerkung
> > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> > > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> unbefugte
> > > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese
> Nachricht
> > > dient lediglich dem Austausch von Informationen und entfaltet keine
> > > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> > > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> > >
> > >
> > > > From: esmond.pitt@bigpond.com
> > > > To: goelenv@gmail.com; users@tomcat.apache.org
> > > > Subject: RE: Tomcat 7 SSL Session ID
> > > > Date: Wed, 5 Dec 2012 09:57:38 +1100
> > > >
> > > > Broken pipes don't invalidate the SSL session. They just break the
> TCP
> > > > connection. The SSL session persists, across multiple TCP
> connections,
> > > > until it is specifically invalidated by someone: for example, timed
> > > > out by the SSLSessionContext.
> > > >
> > > > EJP
> > > >
> > > > _____
> > > >
> > > > From: Vincent Goelen [mailto:goelenv@gmail.com]
> > > > Sent: Wednesday, 5 December 2012 1:15 AM
> > > > To: Tomcat Users List
> > > > Subject: Re: Tomcat 7 SSL Session ID
> > > >
> > > >
> > > > Hey,
> > > >
> > > > thanks for the help!
> > > >
> > > > To be clear, I do not want a 0ms timeout... I'm doing research about
> > > > how "usable" the SSL session tracking option is for session
> management...
> > > > With the standard settings it seems very unstable to me, when sending
> > > > alot of parallel requests I get a broken socket error invalidating
> the
> > > > ssl session and making the session with this id disappear. In this
> > > > case it would seem to me that it's easy to create Denial of Service
> > > > attacks by just sending alot of requests so the user loses his
> session.
> > > >
> > > > By playing with the timeouts I found out this problem doesn't occur
> > > > when I set the timeout to 0, just by playing with the settings.
> > > > Perhaps because this disables the possibility of too many parallel
> > > > connections? I can't find the reason of this in the Tomcat or SSL
> > > specs...
> > > >
> > > > I've added a screenshot of a capture where things go wrong without
> > > > setting a keepAlive.. So I send alot of requests to the server, the
> > > > first clientHello (pck 38943) and the following packets everything
> > > > goes ok, when the application data is being send I get a tcp rst from
> > > > port 54195 (this is the connection that was used for the transactions
> > > > before the current one) ... At this moment my session gets
> invalidates
> > > > making the next SSL handshake a full one with new ID (pckt 40361,
> ...)
> > > >
> > > >
> > > >
> > > >
> > > > 2012/11/29 Christopher Schultz <ch...@christopherschultz.net>
> > > >
> > > >
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > Vincent,
> > > >
> > > >
> > > > On 11/28/12 3:14 AM, Vincent Goelen wrote:
> > > > > When the keepAliveTimeout is not set to "0" I can see in the SSL
> > > > > debug logs the SSL session get's invalidated after some requests
> > > > > with a Broken Pipe exception. Is this because there are too many
> > > > > open connections during the keepAliveTimeout?
> > > >
> > > >
> > > > It's probably because of your pathological keepAliveTimeout. 0ms
> > > > seems, er, low. Why did you choose 0ms?
> > > >
> > > > I haven't looked at the code, so I'm not sure if the elapsed timer
> > > > starts when the last request is completed (which seems reasonable) or
> > > > when the last request started. I suspect the latter. 0ms is awfully
> > > > short. Are you sure that your client is capable of accepting the
> > > > response to the previous request and turn-around and make another
> > > > request across the same channel before 0ms passes?
> > > >
> > > >
> > > > > It also only happens when processing the requests takes some time
> > > > > (fe. storing items in database) or when I put the threat to sleep
> > > > > for testing purpose.
> > > >
> > > >
> > > > So if you have a trivial request (say, HEAD for a static resource),
> > > > you can never get a failure?
> > > >
> > > >
> > > > > When inspecting the traffic I see some tcp-rst packages (problem is
> > > > > here?) from previous connections while the current one is being
> > > > > processed.
> > > >
> > > >
> > > > When you say "current one" what do you mean? If you are using a
> single
> > > > connection with HTTP keepalive, then there is only one connection to
> > > > talk about: you can't get RSTs from "previous connections". You may
> be
> > > > getting TCP RST as the server closes the connection while the client
> > > > is trying to write. Is that what you are experiencing?
> > > >
> > > >
> > > > > My question is why these SSL Sessions get invalidated after alot of
> > > > > quick requests to the server since this gives a problem with my SSL
> > > > > Session tracking since the id changes then.
> > > >
> > > >
> > > > Maybe if you can explain why you want a 0ms keepalive timeout it
> would
> > > > be helpful. If you want to disable keep alives, set
> > > > maxKeepAliveRequests="1". If you want to allow an infinite timeout,
> > > > try using keepAliveTimeout="-1" as the documentation states.
> > > >
> > > > - -chris
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> > > > Comment: GPGTools - http://gpgtools.org
> > > > Comment: Using GnuPG with undefined - http://www.enigmail.net/
> > > >
> > > > iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI
> > > > tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF
> > > > =J7dz
> > > > -----END PGP SIGNATURE-----
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: users-help@tomcat.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>
>
RE: Tomcat 7 SSL Session ID
Posted by Martin Gainty <mg...@hotmail.com>.
can you split the 2 webapps to run on 2 completely different Tomcat instances running on 2 completely different <Connection> configured in server.xml The connection causing the TCP RST is on one tomcat instance and doesnt enable or use the other connections (and does not cause a Session Invalidate) as SSLConnection is disable
the second webapp enables the SSLConnection and does not interact with any other TCP connections as any other TCP or HTTP connections are not enabled in the second TC instance
if you run the simple curl script implementing the keys, password and CACert do you see a key exchange?
(that is the behaviour you want to emulate in your Servlet code)
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Thu, 6 Dec 2012 11:12:26 +0100
> Subject: Re: Tomcat 7 SSL Session ID
> From: goelenv@gmail.com
> To: users@tomcat.apache.org
>
> Hey,
> I'm completely aware that a RST always terminates a TCP connections..
> But in my case, there's an TCP rst from a connection thats already finished
> it's job causing problems for the active connection! At least that's what I
> think is going on here..
> As you can see in the screenshot of my wireshark capture, the TCP rst there
> is not from the connection that's writing application data..
>
> The session get's invalidates here because of an unexpected close of the
> connection which is completely normal regarding the SSL specs.
>
> grts,
> Vincent
>
> 2012/12/5 Esmond Pitt <es...@bigpond.com>
>
> > Vincent
> >
> > RST always terminates a TCP connection. The question is really why was it
> > *sent.* The usual reason is writing to a connection that has already been
> > closed by the peer. Is there an incoming close_notify higher up in the SSL
> > log? I suppose not otherwise an SSLException would have been thrown.
> >
> > Re loss of the SSL session, I suppose it is plausible that SSL discards it
> > on security grounds because of the broken connection.
> >
> > EJP
> >
> > _____
> >
> > From: Vincent Goelen [mailto:goelenv@gmail.com]
> > Sent: Wednesday, 5 December 2012 9:19 PM
> > To: Esmond Pitt
> > Subject: Re: Tomcat 7 SSL Session ID
> >
> >
> >
> > http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 32
> > http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 432
> > http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 32
> > http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 976
> > http-bio-8443-exec-20, handling exception: java.net.SocketException: Broken
> > pipe
> > %% Invalidated: [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA]
> > http-bio-8443-exec-20, SEND TLSv1 ALERT: fatal, description =
> > unexpected_message
> > http-bio-8443-exec-20, WRITE: TLSv1 Alert, length = 32
> > http-bio-8443-exec-20, Exception sending alert: java.net.SocketException:
> > Broken pipe
> > http-bio-8443-exec-20, called closeSocket()
> > http-bio-8443-exec-20, called close()
> > http-bio-8443-exec-20, called closeInternal(true)
> >
> >
> > This is what I get in the SSL debug logs.. It seems to happen when the tcp
> > connection is closed while the application data is being sent.. I think
> > this
> > is a security thing to prevent SSL truncation attacks which sounds quite
> > normal to me.
> >
> > The issue is, why does my tcp connection close there:
> >
> > http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.5
> > 6.png<http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.56.png>
> >
> > The screenshot above is one from where things go wrong when I analyse the
> > traffic, the tcp rst is one from the connection that was used by the
> > previous request.. But why can that rst packet terminate the current active
> > tcp connection?
> >
> >
> > 2012/12/5 Esmond Pitt <es...@bigpond.com>
> >
> >
> > Yes but he *already has* an SSL session which he states is being
> > invalidated. To the limited extent to which I could make sense of your
> > incomprehensible post, it appears to be 100% irrelevant.
> >
> >
> > -----Original Message-----
> > From: Martin Gainty [mailto:mgainty@hotmail.com]
> > Sent: Wednesday, 5 December 2012 11:27 AM
> > To: Tomcat Users List; goelenv@gmail.com
> > Subject: RE: Tomcat 7 SSL Session ID
> >
> >
> >
> > yes but he needs to achieve a reliable connection between himself and the
> > SSLServer (at least until key negotiation has completed) broken pipe(s) are
> > a bear to debug but you have a few tools available to you:
> >
> > netstat SSLServerIP
> > -- if you see ANY intervening nodes hanging more than 4 sec drop from arp
> > cache generally by arp -d ServerIP
> > assuming your ServerIP is is 157.55.85.212 and the physical address of the
> > network you want to connect to is 00-aa-00-62-c6-09 (check with net-admin
> > for the physical-address or eth-addr to use) > arp -s 157.55.85.212
> > 00-aa-00-62-c6-09 .... Adds a static entry.
> > > arp -a .... Displays the arp table.
> > route print will display the routes between you and the SSLServer if you
> > dont see a route referencing the server you may want to add in your own
> > route with
> > route add DESTINATION MASK Mask METRIC NoOfHops Interface
> >
> > InterfaceNumbercheck with net-admin DESTINATION is generally the
> > dotted.quad.of.SSLServercheck with net-admin generally Mask =255.255.255.0
> > will docheck with net admin about which Interface to use..avoid 127.0.0.1
> > (unless testing locally)check with net admin on NoOfHops param ..generally
> >
> > the lower the better use curl (command line url) to check the validity of
> >
> > the certificate, keys and passwordscurl -1 --cacert [file] --key
> >
> > PrivateKey.jks --pass PrivateKeyPass --key-type PEM --pubkey
> > PublicKey.jks-1
> >
> > says use TLSv1check the type of key most keys start out as PEM PEM key ends
> >
> > with .PEM extension ...DER key with .DER... ENG key ends with
> >
> > .ENGhttp://curl.haxx.se/docs/sslcerts.html once you've been able to
> > achieve
> >
> > a Key Exchange you will have a valid SSL Connection..remember binaries have
> > lower CPU so test with a reliable binary first then start debugging your
> > code (i assume you added your CA cert into your local truststore) enough
> > pollution?
> > Martin
> > ______________________________________________
> > Verzicht und Vertraulichkeitanmerkung
> > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> > dient lediglich dem Austausch von Informationen und entfaltet keine
> > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> >
> >
> > > From: esmond.pitt@bigpond.com
> > > To: goelenv@gmail.com; users@tomcat.apache.org
> > > Subject: RE: Tomcat 7 SSL Session ID
> > > Date: Wed, 5 Dec 2012 09:57:38 +1100
> > >
> > > Broken pipes don't invalidate the SSL session. They just break the TCP
> > > connection. The SSL session persists, across multiple TCP connections,
> > > until it is specifically invalidated by someone: for example, timed
> > > out by the SSLSessionContext.
> > >
> > > EJP
> > >
> > > _____
> > >
> > > From: Vincent Goelen [mailto:goelenv@gmail.com]
> > > Sent: Wednesday, 5 December 2012 1:15 AM
> > > To: Tomcat Users List
> > > Subject: Re: Tomcat 7 SSL Session ID
> > >
> > >
> > > Hey,
> > >
> > > thanks for the help!
> > >
> > > To be clear, I do not want a 0ms timeout... I'm doing research about
> > > how "usable" the SSL session tracking option is for session management...
> > > With the standard settings it seems very unstable to me, when sending
> > > alot of parallel requests I get a broken socket error invalidating the
> > > ssl session and making the session with this id disappear. In this
> > > case it would seem to me that it's easy to create Denial of Service
> > > attacks by just sending alot of requests so the user loses his session.
> > >
> > > By playing with the timeouts I found out this problem doesn't occur
> > > when I set the timeout to 0, just by playing with the settings.
> > > Perhaps because this disables the possibility of too many parallel
> > > connections? I can't find the reason of this in the Tomcat or SSL
> > specs...
> > >
> > > I've added a screenshot of a capture where things go wrong without
> > > setting a keepAlive.. So I send alot of requests to the server, the
> > > first clientHello (pck 38943) and the following packets everything
> > > goes ok, when the application data is being send I get a tcp rst from
> > > port 54195 (this is the connection that was used for the transactions
> > > before the current one) ... At this moment my session gets invalidates
> > > making the next SSL handshake a full one with new ID (pckt 40361, ...)
> > >
> > >
> > >
> > >
> > > 2012/11/29 Christopher Schultz <ch...@christopherschultz.net>
> > >
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Vincent,
> > >
> > >
> > > On 11/28/12 3:14 AM, Vincent Goelen wrote:
> > > > When the keepAliveTimeout is not set to "0" I can see in the SSL
> > > > debug logs the SSL session get's invalidated after some requests
> > > > with a Broken Pipe exception. Is this because there are too many
> > > > open connections during the keepAliveTimeout?
> > >
> > >
> > > It's probably because of your pathological keepAliveTimeout. 0ms
> > > seems, er, low. Why did you choose 0ms?
> > >
> > > I haven't looked at the code, so I'm not sure if the elapsed timer
> > > starts when the last request is completed (which seems reasonable) or
> > > when the last request started. I suspect the latter. 0ms is awfully
> > > short. Are you sure that your client is capable of accepting the
> > > response to the previous request and turn-around and make another
> > > request across the same channel before 0ms passes?
> > >
> > >
> > > > It also only happens when processing the requests takes some time
> > > > (fe. storing items in database) or when I put the threat to sleep
> > > > for testing purpose.
> > >
> > >
> > > So if you have a trivial request (say, HEAD for a static resource),
> > > you can never get a failure?
> > >
> > >
> > > > When inspecting the traffic I see some tcp-rst packages (problem is
> > > > here?) from previous connections while the current one is being
> > > > processed.
> > >
> > >
> > > When you say "current one" what do you mean? If you are using a single
> > > connection with HTTP keepalive, then there is only one connection to
> > > talk about: you can't get RSTs from "previous connections". You may be
> > > getting TCP RST as the server closes the connection while the client
> > > is trying to write. Is that what you are experiencing?
> > >
> > >
> > > > My question is why these SSL Sessions get invalidated after alot of
> > > > quick requests to the server since this gives a problem with my SSL
> > > > Session tracking since the id changes then.
> > >
> > >
> > > Maybe if you can explain why you want a 0ms keepalive timeout it would
> > > be helpful. If you want to disable keep alives, set
> > > maxKeepAliveRequests="1". If you want to allow an infinite timeout,
> > > try using keepAliveTimeout="-1" as the documentation states.
> > >
> > > - -chris
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> > > Comment: GPGTools - http://gpgtools.org
> > > Comment: Using GnuPG with undefined - http://www.enigmail.net/
> > >
> > > iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI
> > > tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF
> > > =J7dz
> > > -----END PGP SIGNATURE-----
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
Re: Tomcat 7 SSL Session ID
Posted by Vincent Goelen <go...@gmail.com>.
Hey,
I'm completely aware that a RST always terminates a TCP connections..
But in my case, there's an TCP rst from a connection thats already finished
it's job causing problems for the active connection! At least that's what I
think is going on here..
As you can see in the screenshot of my wireshark capture, the TCP rst there
is not from the connection that's writing application data..
The session get's invalidates here because of an unexpected close of the
connection which is completely normal regarding the SSL specs.
grts,
Vincent
2012/12/5 Esmond Pitt <es...@bigpond.com>
> Vincent
>
> RST always terminates a TCP connection. The question is really why was it
> *sent.* The usual reason is writing to a connection that has already been
> closed by the peer. Is there an incoming close_notify higher up in the SSL
> log? I suppose not otherwise an SSLException would have been thrown.
>
> Re loss of the SSL session, I suppose it is plausible that SSL discards it
> on security grounds because of the broken connection.
>
> EJP
>
> _____
>
> From: Vincent Goelen [mailto:goelenv@gmail.com]
> Sent: Wednesday, 5 December 2012 9:19 PM
> To: Esmond Pitt
> Subject: Re: Tomcat 7 SSL Session ID
>
>
>
> http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 32
> http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 432
> http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 32
> http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 976
> http-bio-8443-exec-20, handling exception: java.net.SocketException: Broken
> pipe
> %% Invalidated: [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA]
> http-bio-8443-exec-20, SEND TLSv1 ALERT: fatal, description =
> unexpected_message
> http-bio-8443-exec-20, WRITE: TLSv1 Alert, length = 32
> http-bio-8443-exec-20, Exception sending alert: java.net.SocketException:
> Broken pipe
> http-bio-8443-exec-20, called closeSocket()
> http-bio-8443-exec-20, called close()
> http-bio-8443-exec-20, called closeInternal(true)
>
>
> This is what I get in the SSL debug logs.. It seems to happen when the tcp
> connection is closed while the application data is being sent.. I think
> this
> is a security thing to prevent SSL truncation attacks which sounds quite
> normal to me.
>
> The issue is, why does my tcp connection close there:
>
> http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.5
> 6.png<http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.56.png>
>
> The screenshot above is one from where things go wrong when I analyse the
> traffic, the tcp rst is one from the connection that was used by the
> previous request.. But why can that rst packet terminate the current active
> tcp connection?
>
>
> 2012/12/5 Esmond Pitt <es...@bigpond.com>
>
>
> Yes but he *already has* an SSL session which he states is being
> invalidated. To the limited extent to which I could make sense of your
> incomprehensible post, it appears to be 100% irrelevant.
>
>
> -----Original Message-----
> From: Martin Gainty [mailto:mgainty@hotmail.com]
> Sent: Wednesday, 5 December 2012 11:27 AM
> To: Tomcat Users List; goelenv@gmail.com
> Subject: RE: Tomcat 7 SSL Session ID
>
>
>
> yes but he needs to achieve a reliable connection between himself and the
> SSLServer (at least until key negotiation has completed) broken pipe(s) are
> a bear to debug but you have a few tools available to you:
>
> netstat SSLServerIP
> -- if you see ANY intervening nodes hanging more than 4 sec drop from arp
> cache generally by arp -d ServerIP
> assuming your ServerIP is is 157.55.85.212 and the physical address of the
> network you want to connect to is 00-aa-00-62-c6-09 (check with net-admin
> for the physical-address or eth-addr to use) > arp -s 157.55.85.212
> 00-aa-00-62-c6-09 .... Adds a static entry.
> > arp -a .... Displays the arp table.
> route print will display the routes between you and the SSLServer if you
> dont see a route referencing the server you may want to add in your own
> route with
> route add DESTINATION MASK Mask METRIC NoOfHops Interface
>
> InterfaceNumbercheck with net-admin DESTINATION is generally the
> dotted.quad.of.SSLServercheck with net-admin generally Mask =255.255.255.0
> will docheck with net admin about which Interface to use..avoid 127.0.0.1
> (unless testing locally)check with net admin on NoOfHops param ..generally
>
> the lower the better use curl (command line url) to check the validity of
>
> the certificate, keys and passwordscurl -1 --cacert [file] --key
>
> PrivateKey.jks --pass PrivateKeyPass --key-type PEM --pubkey
> PublicKey.jks-1
>
> says use TLSv1check the type of key most keys start out as PEM PEM key ends
>
> with .PEM extension ...DER key with .DER... ENG key ends with
>
> .ENGhttp://curl.haxx.se/docs/sslcerts.html once you've been able to
> achieve
>
> a Key Exchange you will have a valid SSL Connection..remember binaries have
> lower CPU so test with a reliable binary first then start debugging your
> code (i assume you added your CA cert into your local truststore) enough
> pollution?
> Martin
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>
>
> > From: esmond.pitt@bigpond.com
> > To: goelenv@gmail.com; users@tomcat.apache.org
> > Subject: RE: Tomcat 7 SSL Session ID
> > Date: Wed, 5 Dec 2012 09:57:38 +1100
> >
> > Broken pipes don't invalidate the SSL session. They just break the TCP
> > connection. The SSL session persists, across multiple TCP connections,
> > until it is specifically invalidated by someone: for example, timed
> > out by the SSLSessionContext.
> >
> > EJP
> >
> > _____
> >
> > From: Vincent Goelen [mailto:goelenv@gmail.com]
> > Sent: Wednesday, 5 December 2012 1:15 AM
> > To: Tomcat Users List
> > Subject: Re: Tomcat 7 SSL Session ID
> >
> >
> > Hey,
> >
> > thanks for the help!
> >
> > To be clear, I do not want a 0ms timeout... I'm doing research about
> > how "usable" the SSL session tracking option is for session management...
> > With the standard settings it seems very unstable to me, when sending
> > alot of parallel requests I get a broken socket error invalidating the
> > ssl session and making the session with this id disappear. In this
> > case it would seem to me that it's easy to create Denial of Service
> > attacks by just sending alot of requests so the user loses his session.
> >
> > By playing with the timeouts I found out this problem doesn't occur
> > when I set the timeout to 0, just by playing with the settings.
> > Perhaps because this disables the possibility of too many parallel
> > connections? I can't find the reason of this in the Tomcat or SSL
> specs...
> >
> > I've added a screenshot of a capture where things go wrong without
> > setting a keepAlive.. So I send alot of requests to the server, the
> > first clientHello (pck 38943) and the following packets everything
> > goes ok, when the application data is being send I get a tcp rst from
> > port 54195 (this is the connection that was used for the transactions
> > before the current one) ... At this moment my session gets invalidates
> > making the next SSL handshake a full one with new ID (pckt 40361, ...)
> >
> >
> >
> >
> > 2012/11/29 Christopher Schultz <ch...@christopherschultz.net>
> >
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Vincent,
> >
> >
> > On 11/28/12 3:14 AM, Vincent Goelen wrote:
> > > When the keepAliveTimeout is not set to "0" I can see in the SSL
> > > debug logs the SSL session get's invalidated after some requests
> > > with a Broken Pipe exception. Is this because there are too many
> > > open connections during the keepAliveTimeout?
> >
> >
> > It's probably because of your pathological keepAliveTimeout. 0ms
> > seems, er, low. Why did you choose 0ms?
> >
> > I haven't looked at the code, so I'm not sure if the elapsed timer
> > starts when the last request is completed (which seems reasonable) or
> > when the last request started. I suspect the latter. 0ms is awfully
> > short. Are you sure that your client is capable of accepting the
> > response to the previous request and turn-around and make another
> > request across the same channel before 0ms passes?
> >
> >
> > > It also only happens when processing the requests takes some time
> > > (fe. storing items in database) or when I put the threat to sleep
> > > for testing purpose.
> >
> >
> > So if you have a trivial request (say, HEAD for a static resource),
> > you can never get a failure?
> >
> >
> > > When inspecting the traffic I see some tcp-rst packages (problem is
> > > here?) from previous connections while the current one is being
> > > processed.
> >
> >
> > When you say "current one" what do you mean? If you are using a single
> > connection with HTTP keepalive, then there is only one connection to
> > talk about: you can't get RSTs from "previous connections". You may be
> > getting TCP RST as the server closes the connection while the client
> > is trying to write. Is that what you are experiencing?
> >
> >
> > > My question is why these SSL Sessions get invalidated after alot of
> > > quick requests to the server since this gives a problem with my SSL
> > > Session tracking since the id changes then.
> >
> >
> > Maybe if you can explain why you want a 0ms keepalive timeout it would
> > be helpful. If you want to disable keep alives, set
> > maxKeepAliveRequests="1". If you want to allow an infinite timeout,
> > try using keepAliveTimeout="-1" as the documentation states.
> >
> > - -chris
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> > Comment: GPGTools - http://gpgtools.org
> > Comment: Using GnuPG with undefined - http://www.enigmail.net/
> >
> > iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI
> > tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF
> > =J7dz
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> >
> >
>
>
>
>
>
>
RE: Tomcat 7 SSL Session ID
Posted by Esmond Pitt <es...@bigpond.com>.
Vincent
RST always terminates a TCP connection. The question is really why was it
*sent.* The usual reason is writing to a connection that has already been
closed by the peer. Is there an incoming close_notify higher up in the SSL
log? I suppose not otherwise an SSLException would have been thrown.
Re loss of the SSL session, I suppose it is plausible that SSL discards it
on security grounds because of the broken connection.
EJP
_____
From: Vincent Goelen [mailto:goelenv@gmail.com]
Sent: Wednesday, 5 December 2012 9:19 PM
To: Esmond Pitt
Subject: Re: Tomcat 7 SSL Session ID
http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 32
http-bio-8443-exec-21, READ: TLSv1 Application Data, length = 432
http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 32
http-bio-8443-exec-20, WRITE: TLSv1 Application Data, length = 976
http-bio-8443-exec-20, handling exception: java.net.SocketException: Broken
pipe
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA]
http-bio-8443-exec-20, SEND TLSv1 ALERT: fatal, description =
unexpected_message
http-bio-8443-exec-20, WRITE: TLSv1 Alert, length = 32
http-bio-8443-exec-20, Exception sending alert: java.net.SocketException:
Broken pipe
http-bio-8443-exec-20, called closeSocket()
http-bio-8443-exec-20, called close()
http-bio-8443-exec-20, called closeInternal(true)
This is what I get in the SSL debug logs.. It seems to happen when the tcp
connection is closed while the application data is being sent.. I think this
is a security thing to prevent SSL truncation attacks which sounds quite
normal to me.
The issue is, why does my tcp connection close there:
http://users.telenet.be/goelenv/Schermafbeelding%202012-12-04%20om%2015.09.5
6.png
The screenshot above is one from where things go wrong when I analyse the
traffic, the tcp rst is one from the connection that was used by the
previous request.. But why can that rst packet terminate the current active
tcp connection?
2012/12/5 Esmond Pitt <es...@bigpond.com>
Yes but he *already has* an SSL session which he states is being
invalidated. To the limited extent to which I could make sense of your
incomprehensible post, it appears to be 100% irrelevant.
-----Original Message-----
From: Martin Gainty [mailto:mgainty@hotmail.com]
Sent: Wednesday, 5 December 2012 11:27 AM
To: Tomcat Users List; goelenv@gmail.com
Subject: RE: Tomcat 7 SSL Session ID
yes but he needs to achieve a reliable connection between himself and the
SSLServer (at least until key negotiation has completed) broken pipe(s) are
a bear to debug but you have a few tools available to you:
netstat SSLServerIP
-- if you see ANY intervening nodes hanging more than 4 sec drop from arp
cache generally by arp -d ServerIP
assuming your ServerIP is is 157.55.85.212 and the physical address of the
network you want to connect to is 00-aa-00-62-c6-09 (check with net-admin
for the physical-address or eth-addr to use) > arp -s 157.55.85.212
00-aa-00-62-c6-09 .... Adds a static entry.
> arp -a .... Displays the arp table.
route print will display the routes between you and the SSLServer if you
dont see a route referencing the server you may want to add in your own
route with
route add DESTINATION MASK Mask METRIC NoOfHops Interface
InterfaceNumbercheck with net-admin DESTINATION is generally the
dotted.quad.of.SSLServercheck with net-admin generally Mask =255.255.255.0
will docheck with net admin about which Interface to use..avoid 127.0.0.1
(unless testing locally)check with net admin on NoOfHops param ..generally
the lower the better use curl (command line url) to check the validity of
the certificate, keys and passwordscurl -1 --cacert [file] --key
PrivateKey.jks --pass PrivateKeyPass --key-type PEM --pubkey PublicKey.jks-1
says use TLSv1check the type of key most keys start out as PEM PEM key ends
with .PEM extension ...DER key with .DER... ENG key ends with
.ENGhttp://curl.haxx.se/docs/sslcerts.html once you've been able to achieve
a Key Exchange you will have a valid SSL Connection..remember binaries have
lower CPU so test with a reliable binary first then start debugging your
code (i assume you added your CA cert into your local truststore) enough
pollution?
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
dient lediglich dem Austausch von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> From: esmond.pitt@bigpond.com
> To: goelenv@gmail.com; users@tomcat.apache.org
> Subject: RE: Tomcat 7 SSL Session ID
> Date: Wed, 5 Dec 2012 09:57:38 +1100
>
> Broken pipes don't invalidate the SSL session. They just break the TCP
> connection. The SSL session persists, across multiple TCP connections,
> until it is specifically invalidated by someone: for example, timed
> out by the SSLSessionContext.
>
> EJP
>
> _____
>
> From: Vincent Goelen [mailto:goelenv@gmail.com]
> Sent: Wednesday, 5 December 2012 1:15 AM
> To: Tomcat Users List
> Subject: Re: Tomcat 7 SSL Session ID
>
>
> Hey,
>
> thanks for the help!
>
> To be clear, I do not want a 0ms timeout... I'm doing research about
> how "usable" the SSL session tracking option is for session management...
> With the standard settings it seems very unstable to me, when sending
> alot of parallel requests I get a broken socket error invalidating the
> ssl session and making the session with this id disappear. In this
> case it would seem to me that it's easy to create Denial of Service
> attacks by just sending alot of requests so the user loses his session.
>
> By playing with the timeouts I found out this problem doesn't occur
> when I set the timeout to 0, just by playing with the settings.
> Perhaps because this disables the possibility of too many parallel
> connections? I can't find the reason of this in the Tomcat or SSL specs...
>
> I've added a screenshot of a capture where things go wrong without
> setting a keepAlive.. So I send alot of requests to the server, the
> first clientHello (pck 38943) and the following packets everything
> goes ok, when the application data is being send I get a tcp rst from
> port 54195 (this is the connection that was used for the transactions
> before the current one) ... At this moment my session gets invalidates
> making the next SSL handshake a full one with new ID (pckt 40361, ...)
>
>
>
>
> 2012/11/29 Christopher Schultz <ch...@christopherschultz.net>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vincent,
>
>
> On 11/28/12 3:14 AM, Vincent Goelen wrote:
> > When the keepAliveTimeout is not set to "0" I can see in the SSL
> > debug logs the SSL session get's invalidated after some requests
> > with a Broken Pipe exception. Is this because there are too many
> > open connections during the keepAliveTimeout?
>
>
> It's probably because of your pathological keepAliveTimeout. 0ms
> seems, er, low. Why did you choose 0ms?
>
> I haven't looked at the code, so I'm not sure if the elapsed timer
> starts when the last request is completed (which seems reasonable) or
> when the last request started. I suspect the latter. 0ms is awfully
> short. Are you sure that your client is capable of accepting the
> response to the previous request and turn-around and make another
> request across the same channel before 0ms passes?
>
>
> > It also only happens when processing the requests takes some time
> > (fe. storing items in database) or when I put the threat to sleep
> > for testing purpose.
>
>
> So if you have a trivial request (say, HEAD for a static resource),
> you can never get a failure?
>
>
> > When inspecting the traffic I see some tcp-rst packages (problem is
> > here?) from previous connections while the current one is being
> > processed.
>
>
> When you say "current one" what do you mean? If you are using a single
> connection with HTTP keepalive, then there is only one connection to
> talk about: you can't get RSTs from "previous connections". You may be
> getting TCP RST as the server closes the connection while the client
> is trying to write. Is that what you are experiencing?
>
>
> > My question is why these SSL Sessions get invalidated after alot of
> > quick requests to the server since this gives a problem with my SSL
> > Session tracking since the id changes then.
>
>
> Maybe if you can explain why you want a 0ms keepalive timeout it would
> be helpful. If you want to disable keep alives, set
> maxKeepAliveRequests="1". If you want to allow an infinite timeout,
> try using keepAliveTimeout="-1" as the documentation states.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI
> tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF
> =J7dz
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
RE: Tomcat 7 SSL Session ID
Posted by Esmond Pitt <es...@bigpond.com>.
Yes but he *already has* an SSL session which he states is being
invalidated. To the limited extent to which I could make sense of your
incomprehensible post, it appears to be 100% irrelevant.
-----Original Message-----
From: Martin Gainty [mailto:mgainty@hotmail.com]
Sent: Wednesday, 5 December 2012 11:27 AM
To: Tomcat Users List; goelenv@gmail.com
Subject: RE: Tomcat 7 SSL Session ID
yes but he needs to achieve a reliable connection between himself and the
SSLServer (at least until key negotiation has completed) broken pipe(s) are
a bear to debug but you have a few tools available to you:
netstat SSLServerIP
-- if you see ANY intervening nodes hanging more than 4 sec drop from arp
cache generally by arp -d ServerIP
assuming your ServerIP is is 157.55.85.212 and the physical address of the
network you want to connect to is 00-aa-00-62-c6-09 (check with net-admin
for the physical-address or eth-addr to use) > arp -s 157.55.85.212
00-aa-00-62-c6-09 .... Adds a static entry.
> arp -a .... Displays the arp table.
route print will display the routes between you and the SSLServer if you
dont see a route referencing the server you may want to add in your own
route with
route add DESTINATION MASK Mask METRIC NoOfHops Interface
InterfaceNumbercheck with net-admin DESTINATION is generally the
dotted.quad.of.SSLServercheck with net-admin generally Mask =255.255.255.0
will docheck with net admin about which Interface to use..avoid 127.0.0.1
(unless testing locally)check with net admin on NoOfHops param ..generally
the lower the better use curl (command line url) to check the validity of
the certificate, keys and passwordscurl -1 --cacert [file] --key
PrivateKey.jks --pass PrivateKeyPass --key-type PEM --pubkey PublicKey.jks-1
says use TLSv1check the type of key most keys start out as PEM PEM key ends
with .PEM extension ...DER key with .DER... ENG key ends with
.ENGhttp://curl.haxx.se/docs/sslcerts.html once you've been able to achieve
a Key Exchange you will have a valid SSL Connection..remember binaries have
lower CPU so test with a reliable binary first then start debugging your
code (i assume you added your CA cert into your local truststore) enough
pollution?
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
dient lediglich dem Austausch von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> From: esmond.pitt@bigpond.com
> To: goelenv@gmail.com; users@tomcat.apache.org
> Subject: RE: Tomcat 7 SSL Session ID
> Date: Wed, 5 Dec 2012 09:57:38 +1100
>
> Broken pipes don't invalidate the SSL session. They just break the TCP
> connection. The SSL session persists, across multiple TCP connections,
> until it is specifically invalidated by someone: for example, timed
> out by the SSLSessionContext.
>
> EJP
>
> _____
>
> From: Vincent Goelen [mailto:goelenv@gmail.com]
> Sent: Wednesday, 5 December 2012 1:15 AM
> To: Tomcat Users List
> Subject: Re: Tomcat 7 SSL Session ID
>
>
> Hey,
>
> thanks for the help!
>
> To be clear, I do not want a 0ms timeout... I'm doing research about
> how "usable" the SSL session tracking option is for session management...
> With the standard settings it seems very unstable to me, when sending
> alot of parallel requests I get a broken socket error invalidating the
> ssl session and making the session with this id disappear. In this
> case it would seem to me that it's easy to create Denial of Service
> attacks by just sending alot of requests so the user loses his session.
>
> By playing with the timeouts I found out this problem doesn't occur
> when I set the timeout to 0, just by playing with the settings.
> Perhaps because this disables the possibility of too many parallel
> connections? I can't find the reason of this in the Tomcat or SSL specs...
>
> I've added a screenshot of a capture where things go wrong without
> setting a keepAlive.. So I send alot of requests to the server, the
> first clientHello (pck 38943) and the following packets everything
> goes ok, when the application data is being send I get a tcp rst from
> port 54195 (this is the connection that was used for the transactions
> before the current one) ... At this moment my session gets invalidates
> making the next SSL handshake a full one with new ID (pckt 40361, ...)
>
>
>
>
> 2012/11/29 Christopher Schultz <ch...@christopherschultz.net>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vincent,
>
>
> On 11/28/12 3:14 AM, Vincent Goelen wrote:
> > When the keepAliveTimeout is not set to "0" I can see in the SSL
> > debug logs the SSL session get's invalidated after some requests
> > with a Broken Pipe exception. Is this because there are too many
> > open connections during the keepAliveTimeout?
>
>
> It's probably because of your pathological keepAliveTimeout. 0ms
> seems, er, low. Why did you choose 0ms?
>
> I haven't looked at the code, so I'm not sure if the elapsed timer
> starts when the last request is completed (which seems reasonable) or
> when the last request started. I suspect the latter. 0ms is awfully
> short. Are you sure that your client is capable of accepting the
> response to the previous request and turn-around and make another
> request across the same channel before 0ms passes?
>
>
> > It also only happens when processing the requests takes some time
> > (fe. storing items in database) or when I put the threat to sleep
> > for testing purpose.
>
>
> So if you have a trivial request (say, HEAD for a static resource),
> you can never get a failure?
>
>
> > When inspecting the traffic I see some tcp-rst packages (problem is
> > here?) from previous connections while the current one is being
> > processed.
>
>
> When you say "current one" what do you mean? If you are using a single
> connection with HTTP keepalive, then there is only one connection to
> talk about: you can't get RSTs from "previous connections". You may be
> getting TCP RST as the server closes the connection while the client
> is trying to write. Is that what you are experiencing?
>
>
> > My question is why these SSL Sessions get invalidated after alot of
> > quick requests to the server since this gives a problem with my SSL
> > Session tracking since the id changes then.
>
>
> Maybe if you can explain why you want a 0ms keepalive timeout it would
> be helpful. If you want to disable keep alives, set
> maxKeepAliveRequests="1". If you want to allow an infinite timeout,
> try using keepAliveTimeout="-1" as the documentation states.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI
> tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF
> =J7dz
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 7 SSL Session ID
Posted by Martin Gainty <mg...@hotmail.com>.
yes but he needs to achieve a reliable connection between himself and the SSLServer (at least until key negotiation has completed)
broken pipe(s) are a bear to debug but you have a few tools available to you:
netstat SSLServerIP
-- if you see ANY intervening nodes hanging more than 4 sec drop from arp cache generally by arp -d ServerIP
assuming your ServerIP is is 157.55.85.212 and the physical address of the network you want to connect to is 00-aa-00-62-c6-09 (check with net-admin for the physical-address or eth-addr to use) > arp -s 157.55.85.212 00-aa-00-62-c6-09 .... Adds a static entry.
> arp -a .... Displays the arp table. route print will display the routes between you and the SSLServer if you dont see a route referencing the server you may want to add in your own route with
route add DESTINATION MASK Mask METRIC NoOfHops Interface InterfaceNumbercheck with net-admin DESTINATION is generally the dotted.quad.of.SSLServercheck with net-admin generally Mask =255.255.255.0 will docheck with net admin about which Interface to use..avoid 127.0.0.1 (unless testing locally)check with net admin on NoOfHops param ..generally the lower the better use curl (command line url) to check the validity of the certificate, keys and passwordscurl -1 --cacert [file] --key PrivateKey.jks --pass PrivateKeyPass --key-type PEM --pubkey PublicKey.jks-1 says use TLSv1check the type of key most keys start out as PEM
PEM key ends with .PEM extension ...DER key with .DER... ENG key ends with .ENGhttp://curl.haxx.se/docs/sslcerts.html once you've been able to achieve a Key Exchange you will have a valid SSL Connection..remember binaries have lower CPU so test with a reliable binary first
then start debugging your code (i assume you added your CA cert into your local truststore) enough pollution?
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> From: esmond.pitt@bigpond.com
> To: goelenv@gmail.com; users@tomcat.apache.org
> Subject: RE: Tomcat 7 SSL Session ID
> Date: Wed, 5 Dec 2012 09:57:38 +1100
>
> Broken pipes don't invalidate the SSL session. They just break the TCP
> connection. The SSL session persists, across multiple TCP connections, until
> it is specifically invalidated by someone: for example, timed out by the
> SSLSessionContext.
>
> EJP
>
> _____
>
> From: Vincent Goelen [mailto:goelenv@gmail.com]
> Sent: Wednesday, 5 December 2012 1:15 AM
> To: Tomcat Users List
> Subject: Re: Tomcat 7 SSL Session ID
>
>
> Hey,
>
> thanks for the help!
>
> To be clear, I do not want a 0ms timeout... I'm doing research about how
> "usable" the SSL session tracking option is for session management...
> With the standard settings it seems very unstable to me, when sending alot
> of parallel requests I get a broken socket error invalidating the ssl
> session and making the session with this id disappear. In this case it would
> seem to me that it's easy to create Denial of Service attacks by just
> sending alot of requests so the user loses his session.
>
> By playing with the timeouts I found out this problem doesn't occur when I
> set the timeout to 0, just by playing with the settings. Perhaps because
> this disables the possibility of too many parallel connections? I can't find
> the reason of this in the Tomcat or SSL specs...
>
> I've added a screenshot of a capture where things go wrong without setting a
> keepAlive.. So I send alot of requests to the server, the first clientHello
> (pck 38943) and the following packets everything goes ok, when the
> application data is being send I get a tcp rst from port 54195 (this is the
> connection that was used for the transactions before the current one) ... At
> this moment my session gets invalidates making the next SSL handshake a full
> one with new ID (pckt 40361, ...)
>
>
>
>
> 2012/11/29 Christopher Schultz <ch...@christopherschultz.net>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vincent,
>
>
> On 11/28/12 3:14 AM, Vincent Goelen wrote:
> > When the keepAliveTimeout is not set to "0" I can see in the SSL
> > debug logs the SSL session get's invalidated after some requests
> > with a Broken Pipe exception. Is this because there are too many
> > open connections during the keepAliveTimeout?
>
>
> It's probably because of your pathological keepAliveTimeout. 0ms
> seems, er, low. Why did you choose 0ms?
>
> I haven't looked at the code, so I'm not sure if the elapsed timer
> starts when the last request is completed (which seems reasonable) or
> when the last request started. I suspect the latter. 0ms is awfully
> short. Are you sure that your client is capable of accepting the
> response to the previous request and turn-around and make another
> request across the same channel before 0ms passes?
>
>
> > It also only happens when processing the requests takes some time
> > (fe. storing items in database) or when I put the threat to sleep
> > for testing purpose.
>
>
> So if you have a trivial request (say, HEAD for a static resource),
> you can never get a failure?
>
>
> > When inspecting the traffic I see some tcp-rst packages (problem is
> > here?) from previous connections while the current one is being
> > processed.
>
>
> When you say "current one" what do you mean? If you are using a single
> connection with HTTP keepalive, then there is only one connection to
> talk about: you can't get RSTs from "previous connections". You may be
> getting TCP RST as the server closes the connection while the client
> is trying to write. Is that what you are experiencing?
>
>
> > My question is why these SSL Sessions get invalidated after alot of
> > quick requests to the server since this gives a problem with my SSL
> > Session tracking since the id changes then.
>
>
> Maybe if you can explain why you want a 0ms keepalive timeout it would
> be helpful. If you want to disable keep alives, set
> maxKeepAliveRequests="1". If you want to allow an infinite timeout,
> try using keepAliveTimeout="-1" as the documentation states.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI
> tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF
> =J7dz
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
Re: [OT] Tomcat 7 SSL Session ID
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 12/5/12 2:49 AM, André Warnier wrote:
> Esmond Pitt wrote:
>> Broken pipes don't invalidate the SSL session. They just break
>> the TCP connection. The SSL session persists, across multiple TCP
>> connections, until it is specifically invalidated by someone: for
>> example, timed out by the SSLSessionContext.
>>
> Ah. That would explain some other (totally unrelated) phenomenon
> which I had noticed and which puzzled me. I didn't know that.
> Thanks for the info.
Yes. SSL sessions are essentially an optimization because SSL key
exchange and setup are fairly expensive (it uses asymmetric,
public-key encryption which is sloooow). Once the session is
established, a symmetric encryption key is used and the client and
server generally refer to the session id for a period of time.
At some interval, the session is re-negotiated ostensibly to improve
security (to limit the lifetime of the encryption keys) though there
have been some vulnerabilities identified in recent years (you have
probably heard the phrase "unsafe renegotiation") with this mechanism.
When the session times out (or is explicitly destroyed... I don't know
the specific mechanism for accomplishing this as the client is not
guaranteed to ever return for more data), everything must be
renegotiated from scratch and a new session is created.
Again, this has absolutely nothing to do with HttpSession, nor does it
really have anything to do with HTTP at all -- that just happens to be
the protocol tunneled through TLS in this case. The fact that the OP
is playing around with keepalive timeouts really shouldn't have any
bearing on what's going on, here: Tomcat's documentation says that the
default SSL session timeout is 24 hours. That means that, 24 hours
after a client makes a single SSL connection, Tomcat will expire the
session. I don't know that a client can specifically ask the server to
expire an SSL session. So, something weird is definitely going on. I
can't yet figure out if this is a Tomcat bug, a configuration snafu,
or a complete misunderstanding of SSL sessions on the OP's part.
Honestly, I was hoping that after extracting more information from the
OP, someone with more low-level knowledge of JSSE and/or OpenSSL
(Filip or Konstantin, probably) would chime-in with some more useful
thoughts.
The "description" section on Wikipedia is definitely worth the read:
http://en.wikipedia.org/wiki/Transport_Layer_Security
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC/cI8ACgkQ9CaO5/Lv0PDVeQCgw02zqPBMWIIoIuhlXd18NHd/
UmUAn0vj2QxtyrYPN5s7MJWZeChG4zj8
=CfQX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Tomcat 7 SSL Session ID
Posted by André Warnier <aw...@ice-sa.com>.
Esmond Pitt wrote:
> Broken pipes don't invalidate the SSL session. They just break the TCP
> connection. The SSL session persists, across multiple TCP connections, until
> it is specifically invalidated by someone: for example, timed out by the
> SSLSessionContext.
>
Ah. That would explain some other (totally unrelated) phenomenon which I had noticed and
which puzzled me.
I didn't know that. Thanks for the info.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 7 SSL Session ID
Posted by Esmond Pitt <es...@bigpond.com>.
Broken pipes don't invalidate the SSL session. They just break the TCP
connection. The SSL session persists, across multiple TCP connections, until
it is specifically invalidated by someone: for example, timed out by the
SSLSessionContext.
EJP
_____
From: Vincent Goelen [mailto:goelenv@gmail.com]
Sent: Wednesday, 5 December 2012 1:15 AM
To: Tomcat Users List
Subject: Re: Tomcat 7 SSL Session ID
Hey,
thanks for the help!
To be clear, I do not want a 0ms timeout... I'm doing research about how
"usable" the SSL session tracking option is for session management...
With the standard settings it seems very unstable to me, when sending alot
of parallel requests I get a broken socket error invalidating the ssl
session and making the session with this id disappear. In this case it would
seem to me that it's easy to create Denial of Service attacks by just
sending alot of requests so the user loses his session.
By playing with the timeouts I found out this problem doesn't occur when I
set the timeout to 0, just by playing with the settings. Perhaps because
this disables the possibility of too many parallel connections? I can't find
the reason of this in the Tomcat or SSL specs...
I've added a screenshot of a capture where things go wrong without setting a
keepAlive.. So I send alot of requests to the server, the first clientHello
(pck 38943) and the following packets everything goes ok, when the
application data is being send I get a tcp rst from port 54195 (this is the
connection that was used for the transactions before the current one) ... At
this moment my session gets invalidates making the next SSL handshake a full
one with new ID (pckt 40361, ...)
2012/11/29 Christopher Schultz <ch...@christopherschultz.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vincent,
On 11/28/12 3:14 AM, Vincent Goelen wrote:
> When the keepAliveTimeout is not set to "0" I can see in the SSL
> debug logs the SSL session get's invalidated after some requests
> with a Broken Pipe exception. Is this because there are too many
> open connections during the keepAliveTimeout?
It's probably because of your pathological keepAliveTimeout. 0ms
seems, er, low. Why did you choose 0ms?
I haven't looked at the code, so I'm not sure if the elapsed timer
starts when the last request is completed (which seems reasonable) or
when the last request started. I suspect the latter. 0ms is awfully
short. Are you sure that your client is capable of accepting the
response to the previous request and turn-around and make another
request across the same channel before 0ms passes?
> It also only happens when processing the requests takes some time
> (fe. storing items in database) or when I put the threat to sleep
> for testing purpose.
So if you have a trivial request (say, HEAD for a static resource),
you can never get a failure?
> When inspecting the traffic I see some tcp-rst packages (problem is
> here?) from previous connections while the current one is being
> processed.
When you say "current one" what do you mean? If you are using a single
connection with HTTP keepalive, then there is only one connection to
talk about: you can't get RSTs from "previous connections". You may be
getting TCP RST as the server closes the connection while the client
is trying to write. Is that what you are experiencing?
> My question is why these SSL Sessions get invalidated after alot of
> quick requests to the server since this gives a problem with my SSL
> Session tracking since the id changes then.
Maybe if you can explain why you want a 0ms keepalive timeout it would
be helpful. If you want to disable keep alives, set
maxKeepAliveRequests="1". If you want to allow an infinite timeout,
try using keepAliveTimeout="-1" as the documentation states.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI
tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF
=J7dz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 SSL Session ID
Posted by Vincent Goelen <go...@gmail.com>.
Thanks again for the fast response, sorry for being unclear about some
parts.. First time using the mailing list
I'm using Apache Tomcat Version 7.0.32 on a mac os x 10.7.5, I've tested it
on linux Virtual machine too, got same problems. I'm using JDK 1.6 (don't
think it has any importance here)
Alot is kind of variable, depends on how long the processing of the request
takes, for example when I put a sleep of 1 sec in my jsp code the problem
occurs after about 6 requests, in another test example where I just write
some things to a database it takes more requests, sometimes about 100,
sometimes less it's not really a fixed number I can put on it.
To be clear, it's indeed the SSL session that gets invalidated, not the
httpsession... But by the invalidation, the httpsession's identifier (which
is the SSL session id) is gone so the httpsession becomes useless as well..
http://users.telenet.be/goelenv/Archief.zip
In this zip file you can find 3 files:
- a log which is the ssl debug log from tomcat, there you can find an
example of the invalidation at line 2592 (log mislopen.log)
- a wireshark capture file where things go wrong are captured
(Capture_TomcatSSLFout) => here things go wrong at packet 40361 you can
best filter on "tcp.port == 8443" to filter traffic between server and
client
- a screenshot of where things go wrong in case you can't open the
wireshark capture (Schermafbeelding 2012-12-04 om 15.09.56)
Again many thanks!
Vincent
2012/12/4 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vincent,
>
> On 12/4/12 9:15 AM, Vincent Goelen wrote:
> > To be clear, I do not want a 0ms timeout... I'm doing research
> > about how "usable" the SSL session tracking option is for session
> > management... With the standard settings it seems very unstable to
> > me, when sending alot of parallel requests I get a broken socket
> > error invalidating the ssl session and making the session with this
> > id disappear. In this case it would seem to me that it's easy to
> > create Denial of Service attacks by just sending alot of requests
> > so the user loses his session.
>
> Forgive me, but it sounded like you set timeout=0 and then started
> getting weird behavior. I would have totally expected weird behavior
> with timeout=0 so that's why I was asking.
>
> You are going to need to provide a lot more detail about the
> session-invalidation (you're talking about *SSL session* invalidation,
> not HttpSession invalidation, right?) you are observing if you want to
> get any help. Lots of technical details, logs, explicit configuration
> (even if it is the default), specific version numbers ("Tomcat 7"
> isn't good enough), etc.
>
> You should also try it on a couple of different platforms. What
> happens on Linux? Windows? Solaris? Whatever you've got laying around.
>
> > I've added a screenshot of a capture where things go wrong without
> > setting a keepAlive.
>
> Attachments get stripped from this list: please post the file
> somewhere else and provide a link.
>
> > So I send alot of requests to the server,
>
> How many is a lot? Serial or parallel? How many parallel threads? Be
> specific.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlC+IQEACgkQ9CaO5/Lv0PBqwACgrkEoqbtzM/jlPiy2SFKhqlIB
> PzkAoIMGBHJickA7JynoX81B0GarvYzd
> =SAlr
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat 7 SSL Session ID
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vincent,
On 12/4/12 9:15 AM, Vincent Goelen wrote:
> To be clear, I do not want a 0ms timeout... I'm doing research
> about how "usable" the SSL session tracking option is for session
> management... With the standard settings it seems very unstable to
> me, when sending alot of parallel requests I get a broken socket
> error invalidating the ssl session and making the session with this
> id disappear. In this case it would seem to me that it's easy to
> create Denial of Service attacks by just sending alot of requests
> so the user loses his session.
Forgive me, but it sounded like you set timeout=0 and then started
getting weird behavior. I would have totally expected weird behavior
with timeout=0 so that's why I was asking.
You are going to need to provide a lot more detail about the
session-invalidation (you're talking about *SSL session* invalidation,
not HttpSession invalidation, right?) you are observing if you want to
get any help. Lots of technical details, logs, explicit configuration
(even if it is the default), specific version numbers ("Tomcat 7"
isn't good enough), etc.
You should also try it on a couple of different platforms. What
happens on Linux? Windows? Solaris? Whatever you've got laying around.
> I've added a screenshot of a capture where things go wrong without
> setting a keepAlive.
Attachments get stripped from this list: please post the file
somewhere else and provide a link.
> So I send alot of requests to the server,
How many is a lot? Serial or parallel? How many parallel threads? Be
specific.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC+IQEACgkQ9CaO5/Lv0PBqwACgrkEoqbtzM/jlPiy2SFKhqlIB
PzkAoIMGBHJickA7JynoX81B0GarvYzd
=SAlr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 SSL Session ID
Posted by Vincent Goelen <go...@gmail.com>.
Hey,
thanks for the help!
To be clear, I do not want a 0ms timeout... I'm doing research about how
"usable" the SSL session tracking option is for session management...
With the standard settings it seems very unstable to me, when sending alot
of parallel requests I get a broken socket error invalidating the ssl
session and making the session with this id disappear. In this case it
would seem to me that it's easy to create Denial of Service attacks by just
sending alot of requests so the user loses his session.
By playing with the timeouts I found out this problem doesn't occur when I
set the timeout to 0, just by playing with the settings. Perhaps because
this disables the possibility of too many parallel connections? I can't
find the reason of this in the Tomcat or SSL specs...
I've added a screenshot of a capture where things go wrong without setting
a keepAlive.. So I send alot of requests to the server, the first
clientHello (pck 38943) and the following packets everything goes ok, when
the application data is being send I get a tcp rst from port 54195 (this is
the connection that was used for the transactions before the current one)
... At this moment my session gets invalidates making the next SSL
handshake a full one with new ID (pckt 40361, ...)
2012/11/29 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vincent,
>
> On 11/28/12 3:14 AM, Vincent Goelen wrote:
> > When the keepAliveTimeout is not set to "0" I can see in the SSL
> > debug logs the SSL session get's invalidated after some requests
> > with a Broken Pipe exception. Is this because there are too many
> > open connections during the keepAliveTimeout?
>
> It's probably because of your pathological keepAliveTimeout. 0ms
> seems, er, low. Why did you choose 0ms?
>
> I haven't looked at the code, so I'm not sure if the elapsed timer
> starts when the last request is completed (which seems reasonable) or
> when the last request started. I suspect the latter. 0ms is awfully
> short. Are you sure that your client is capable of accepting the
> response to the previous request and turn-around and make another
> request across the same channel before 0ms passes?
>
> > It also only happens when processing the requests takes some time
> > (fe. storing items in database) or when I put the threat to sleep
> > for testing purpose.
>
> So if you have a trivial request (say, HEAD for a static resource),
> you can never get a failure?
>
> > When inspecting the traffic I see some tcp-rst packages (problem is
> > here?) from previous connections while the current one is being
> > processed.
>
> When you say "current one" what do you mean? If you are using a single
> connection with HTTP keepalive, then there is only one connection to
> talk about: you can't get RSTs from "previous connections". You may be
> getting TCP RST as the server closes the connection while the client
> is trying to write. Is that what you are experiencing?
>
> > My question is why these SSL Sessions get invalidated after alot of
> > quick requests to the server since this gives a problem with my SSL
> > Session tracking since the id changes then.
>
> Maybe if you can explain why you want a 0ms keepalive timeout it would
> be helpful. If you want to disable keep alives, set
> maxKeepAliveRequests="1". If you want to allow an infinite timeout,
> try using keepAliveTimeout="-1" as the documentation states.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI
> tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF
> =J7dz
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat 7 SSL Session ID
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vincent,
On 11/28/12 3:14 AM, Vincent Goelen wrote:
> When the keepAliveTimeout is not set to "0" I can see in the SSL
> debug logs the SSL session get's invalidated after some requests
> with a Broken Pipe exception. Is this because there are too many
> open connections during the keepAliveTimeout?
It's probably because of your pathological keepAliveTimeout. 0ms
seems, er, low. Why did you choose 0ms?
I haven't looked at the code, so I'm not sure if the elapsed timer
starts when the last request is completed (which seems reasonable) or
when the last request started. I suspect the latter. 0ms is awfully
short. Are you sure that your client is capable of accepting the
response to the previous request and turn-around and make another
request across the same channel before 0ms passes?
> It also only happens when processing the requests takes some time
> (fe. storing items in database) or when I put the threat to sleep
> for testing purpose.
So if you have a trivial request (say, HEAD for a static resource),
you can never get a failure?
> When inspecting the traffic I see some tcp-rst packages (problem is
> here?) from previous connections while the current one is being
> processed.
When you say "current one" what do you mean? If you are using a single
connection with HTTP keepalive, then there is only one connection to
talk about: you can't get RSTs from "previous connections". You may be
getting TCP RST as the server closes the connection while the client
is trying to write. Is that what you are experiencing?
> My question is why these SSL Sessions get invalidated after alot of
> quick requests to the server since this gives a problem with my SSL
> Session tracking since the id changes then.
Maybe if you can explain why you want a 0ms keepalive timeout it would
be helpful. If you want to disable keep alives, set
maxKeepAliveRequests="1". If you want to allow an infinite timeout,
try using keepAliveTimeout="-1" as the documentation states.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC3w6YACgkQ9CaO5/Lv0PDX/QCfcPmdRD/FSyDB51QdOqgqwGbI
tLwAmweVvlGCGqU2eAdYtrzezwkEPhZF
=J7dz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org