tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Goelen <goel...@gmail.com>
Subject Re: Tomcat 7 SSL Session ID
Date Mon, 10 Dec 2012 13:48:30 GMT
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 <mgainty@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 <esmond.pitt@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 <esmond.pitt@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 <chris@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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message