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: goel...@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 <mgai...@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: goel...@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.p...@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:goel...@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.p...@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:mgai...@hotmail.com]
> > > > Sent: Wednesday, 5 December 2012 11:27 AM
> > > > To: Tomcat Users List; goel...@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.p...@bigpond.com
> > > > > To: goel...@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:goel...@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-unsubscr...@tomcat.apache.org
> > > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
