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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
