Re: [OT] Getting DH parameters from an SSLSocket

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/29/16 5:38 AM, Mark Thomas wrote:
> On 28/09/2016 22:14, Christopher Schultz wrote:
>> Mark,
>> 
>> On 9/19/16 4:32 PM, Mark Thomas wrote:
>>> On 19/09/2016 21:20, Christopher Schultz wrote:
 All,
 
 On 8/31/16 12:45 PM, Christopher Schultz wrote:
> All,
 
> This isn't Tomcat-related, but many folks on this list
> have this kind of experience, so I'm asking in case anyone
> knows.
 
> I'd like to make an HTTPS connection to a server and, if
> I'm using non-ephemeral DH key exchange, I'd like to know
> what the parameters are for that connection. Actually, I
> don't really care if it's ephemeral or not.
 
> What I'm looking for is the ability to make a connection
> and then warn if the connection is using "weak" DH
> parameters. Is that something I can check at
> connection-time? Or is the set of DH parameters (or, more
> specifically, the *length* of those parameters, in bits)
> defined by the cipher suite itself?
 
> For example, the Qualys community thread has an
> illustration of the cipher suites that SSLLabs considers
> "weak" (well, everyone considers them weak... they just
> have a public tool which complains about them): 
> https://community.qualys.com/thread/14821
 
> They specifically mention e.g. 
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 which is cipher suite
> 0x9f and mention the DH parameters. Are those parameters'
> parameters baked-into the cipher suite (meaning they are
> *always* 1024-bit) or is this a configuration of the server
> that makes those cipher suites weak due to the specific DH
> parameter choice?
 
> In either case, I'd like to be able to sniff that
> information from the connection if at all possible. Does
> anyone know if this can be done, and how?
 
> Thanks, -chris
 
 It seems that this isn't possible.
 
 Does anyone on the list have the karma required to file an 
 enhancement request for the Java API? Or does everything need
 to be a darned JSR?
>> 
>>> I recommend starting with the security-...@openjdk.java.net
>>> mailing list.
>> 
>>> As far as I know, the process is to raise a bug/enhancement 
>>> request against Java. From my own experience with the memory
>>> leak bugs, it helps a lot if an OpenJDK committer has already
>>> agreed to try and do something about it.
>> 
>> So... crickets so far.
>> 
>> Any suggestions?
> 
> Open an enhancement request and the next time Rory posts to the dev
> list about Java 9 respond with a request to look at your
> enhancement request.
> 
> The more you can tie it back to something that Tomcat needs to
> improve security, the greater the chances of something happening.

Okay.

> That is how I got the memory leak stuff fixed. The advantage I had
> was they were all clear bugs and I had simple tests cases (most of
> the time) to demonstrate them.

Yeah, this is clearly an enhancement request. So, maybe less incentive.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX7UbWAAoJEBzwKT+lPKRYSPMP/1KdZsvY2TqUKqYsu0NSebOF
4jaZVdtG/09JUBjS74qVtujqSS2Kn+wxxqljzZJYL5/sekiXJBu4kjGNwFy1azsM
VkpH1es8x/xGunfUYWDSxYDmofHjaOhPRXm0zNN42ZFb/b2ssa5x5I0IB+xBwuuS
PM/wLcbkUmm/RoabVEUO6Eb7SABKIOCokd5SGNDOY8bPb6xeFrjRDKv5U+6U9cIM
XEXVcOY5UvIwBTxa9mCxOB8uHIC3TiEhVecxToFRD5WK7FJ9BfDpBqLBKYdNK+fF
8500tYH8iWYLO1MmBKS3xsppUIiDu2a1xF7TXTQR41nM6NMeNF6TSBQQoUp0N+bU
F6NNKUHRZMNkv6C1XX7t8gFGg/xP1hYw0IvNkkZjKakptnW84bm1P0VY6D+ZI0TS
HOGpkg8jP7oNrsQEX+IK3HjEYRAHT+j0HR8u6q0Zmal3bkqJ9cjXsYMLHUOEgZAB
BFnawEHsvb87mU3E1uK58F3zzBvnyLq1eU4q9gq1BBQ2vZpufIuYnH2u9l3rWQda
ldG5pjZ/zcHkokO8O0OPo8Eu3MOsG4reSHHIITnLH1AlyaMMyOBCkqpnBZttTIMm
gV3QVI5bjpQ3RNhS0nKZkZycmIBvCgbreMo5zpVZsbe7leHh4SPwSU5ccJiL1YOd
8/83xNVMFvBPx4eX3UWZ
=Z14m
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

HTTP/2 PushBuilder.push() synchronous?

[Brian Clozel]

Hi,

Looking at previous Servlet 4.0 EG e-mails [1] and the PushBuilder.push()
API [2], it seems the current version returns true if the PUSH_PROMISE
frame + headers were sent, meaning the client can still reset that stream
and refuse to receive the response that goes with it.

Now looking at former EG e-mails, it seems that a previous version of the
spec stated that push "returns immediately without blocking" [3]. But this
API, and the implementation as far as I understand things [4], seems
synchronous. Or does that writing does not happen directly on the actual
socket but is later dispatched on another thread?

In general, I'm trying to understand how I can use that API in an async,
non-blocking way and if the application really needs to know if the Push
promise "happened" or not...

Cheers,

[1] https://java.net/projects/servlet-spec/lists/jsr369-
experts/archive/2016-03/message/0
[2] https://github.com/apache/tomcat/blob/trunk/java/javax/s
ervlet/http/PushBuilder.java#L161-L178
[3] https://java.net/projects/servlet-spec/lists/jsr369-expe
rts/archive/2015-12/message/8
[4] https://github.com/apache/tomcat/blob/trunk/java/org/apa
che/coyote/http2/Http2UpgradeHandler.java#L1036
--
Brian Clozel

RE: JreMemoryLeakPreventionListener docs example

[Berneburg, Cris J. - US]

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, September 28, 2016 4:43 PM
To: Tomcat Users List
Subject: Re: JreMemoryLeakPreventionListener docs example

 It's a slippery slope, my friend. After this, I'll be
 pressuring you for trivial code patches :)
>>>
>>> Gah, you tricked me into downloading the whole Tomcat
>>> source code!  The slippery slope slide has already
>>> started!  :-)
>> 
>> Excellent.
>
> I really hope you were tenting your fingers[1] when you
> said that.
>
> - -chris
>
> [1] https://thestranded.files.wordpress.com/2014/02/burns-excellent.gif

In my imagination he pronounced it, "Ecellent".

--
Cris Berneburg
CACI Lead Software Engineer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: JreMemoryLeakPreventionListener docs example

[Berneburg, Cris J. - US]

Chris and Mark

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, September 28, 2016 2:21 PM
To: Tomcat Users List
Subject: Re: JreMemoryLeakPreventionListener docs example

[SNIP]

>>> attach it to a Bugzilla ticket describing what you are
>>> trying to do (e.g. "Improve documentation for
>>> JreMemoryLeakPreventionListener") .
>> 
>> What Tomcat product should I use when creating the bug?
>> There are multiple versions to choose from, but I checked
>> out code from the trunk, not a specific branch.
>
> Tomcat 9 please.

Done.  Bug #60188, "Improve documentation for JreMemoryLeakPreventionListener" 
submitted with attachment "Chris_Schultz_is_Awesome.diff" as the patch.  ;-)

--
Cris Berneburg
CACI Lead Software Engineer

Re: [OT] Getting DH parameters from an SSLSocket

[Mark Thomas]

On 28/09/2016 22:14, Christopher Schultz wrote:
> Mark,
> 
> On 9/19/16 4:32 PM, Mark Thomas wrote:
>> On 19/09/2016 21:20, Christopher Schultz wrote:
>>> All,
>>>
>>> On 8/31/16 12:45 PM, Christopher Schultz wrote:
 All,
>>>
 This isn't Tomcat-related, but many folks on this list have
 this kind of experience, so I'm asking in case anyone knows.
>>>
 I'd like to make an HTTPS connection to a server and, if I'm
 using non-ephemeral DH key exchange, I'd like to know what the 
 parameters are for that connection. Actually, I don't really
 care if it's ephemeral or not.
>>>
 What I'm looking for is the ability to make a connection and
 then warn if the connection is using "weak" DH parameters. Is
 that something I can check at connection-time? Or is the set of
 DH parameters (or, more specifically, the *length* of those 
 parameters, in bits) defined by the cipher suite itself?
>>>
 For example, the Qualys community thread has an illustration
 of the cipher suites that SSLLabs considers "weak" (well,
 everyone considers them weak... they just have a public tool
 which complains about them):
 https://community.qualys.com/thread/14821
>>>
 They specifically mention e.g.
 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 which is cipher suite 0x9f
 and mention the DH parameters. Are those parameters' parameters
 baked-into the cipher suite (meaning they are *always*
 1024-bit) or is this a configuration of the server that makes
 those cipher suites weak due to the specific DH parameter
 choice?
>>>
 In either case, I'd like to be able to sniff that information
 from the connection if at all possible. Does anyone know if
 this can be done, and how?
>>>
 Thanks, -chris
>>>
>>> It seems that this isn't possible.
>>>
>>> Does anyone on the list have the karma required to file an
>>> enhancement request for the Java API? Or does everything need to
>>> be a darned JSR?
> 
>> I recommend starting with the security-...@openjdk.java.net mailing
>> list.
> 
>> As far as I know, the process is to raise a bug/enhancement
>> request against Java. From my own experience with the memory leak
>> bugs, it helps a lot if an OpenJDK committer has already agreed to
>> try and do something about it.
> 
> So... crickets so far.
> 
> Any suggestions?

Open an enhancement request and the next time Rory posts to the dev list
about Java 9 respond with a request to look at your enhancement request.

The more you can tie it back to something that Tomcat needs to improve
security, the greater the chances of something happening.

That is how I got the memory leak stuff fixed. The advantage I had was
they were all clear bugs and I had simple tests cases (most of the time)
to demonstrate them.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Async servlet and request recycling

[Violeta Georgieva]

Hi,

2016-09-29 10:14 GMT+03:00 Thomas Boniface :
>
> The tomcat version is 7.0.64.

I would recommend you to verify the behaviour against the latest Tomcat 7
(7.0.72).
We have changes in the async processing since 7.0.64.
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Regards,
Violeta

> Thomas
>
> 2016-09-28 22:43 GMT+02:00 Christopher Schultz <
ch...@christopherschultz.net
> >:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Thomas,
> >
> > On 9/28/16 11:55 AM, Thomas Boniface wrote:
> > > Hi,
> > >
> > > When a client calls an asynchronous servlet and closes the
> > > connection a java.io.IOException: Broken pipe is catched by Tomcat
> > > level when the webapp tries to write to the socket.
> > >
> > > This exception is not transmited to the webapp level but it seems
> > > the request has been recycled (all content is reinitialised), in
> > > such a case it impossible for the webapp to retrieve the
> > > AsyncContext from the HttpServletRequest making the AsyncContext
> > > complete call impossible.
> > >
> > > Activating the tomcat logging for AsyncContext
> > > (org.apache.catalina.core.AsyncContextImpl.level = FINE) shows the
> > > recycle method is called but not the complete method, what seems to
> > > confirm my assumption. In a use case were the client waits for the
> > > response, I can see both complete and recycle are called.
> > >
> > > My question is, what is the impact of the complete not being called
> > > on the AsyncContext, is the socket cleaned up properly ?
> >
> > Tomcat version?
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Comment: GPGTools - http://gpgtools.org
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQIcBAEBCAAGBQJX7CtcAAoJEBzwKT+lPKRYwekP/R1wirv0g7wJ3uR1Xk4mYIQo
> > jPUYBirzVcewTWrDUpOe4BdXUBzgk7zDVrOsWU9PGlc0Prwik9YHeFWlG9ItxeEs
> > 0ZJ0vJ1z6Od0KsxN6E8KobsE3rQu+td1Mh7d0g76zbHQKiLmrJNb8/hGuHVQr9Fd
> > M597bec0JYiQSXU+8/SMErx/bdoA8HcApaeJpnl/RuCLfYwQ5ZSS/e0SCuSqMi1W
> > bEU0vj0pBfK6h1WuweCRoBL5Shxa2XBpbc8nlPgb7IHNlQ15dwlD10nnuYDLb7DR
> > VmOYEx2fmynZ/fOajfTsHoWUpoHjK47vMjtLUpIXARN8LY6tR2A2iUqJ6gXlM+QL
> > gNRkucxkI3RSV3U7ipx7y5IJTglFC7uAyFlJpPLx8gLhGWSUz+q46lDr+332kF5x
> > VU7rKLY/3RcSJG0ZLfIzPly5tz8wssMvwu94nI8lQb4SweEJDa6cT5Z8aUUTFaf6
> > kjy34jSgsi6QyN+NK9WKapdDNzvIo1X18zK2CqfDSeyBsgprU62o1P8R/BxIiM9f
> > YAnK98kPtmmKyJHcS7+fBngO1/TZvsdGlYj+cXcnCNi0Fnp50WKlHOPb6wcZo5q5
> > lcpLkwj4izmdgW8rONjMDAZj3gal7OKw0WQ/srU6XIfUa1kgR0NAtb7YQGvHJA5g
> > ljFdLIuRnMu+43OsbSKC
> > =zrQ5
> > -END PGP SIGNATURE-
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >

Re: Async servlet and request recycling

[Thomas Boniface]

The tomcat version is 7.0.64.

Thomas

2016-09-28 22:43 GMT+02:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Thomas,
>
> On 9/28/16 11:55 AM, Thomas Boniface wrote:
> > Hi,
> >
> > When a client calls an asynchronous servlet and closes the
> > connection a java.io.IOException: Broken pipe is catched by Tomcat
> > level when the webapp tries to write to the socket.
> >
> > This exception is not transmited to the webapp level but it seems
> > the request has been recycled (all content is reinitialised), in
> > such a case it impossible for the webapp to retrieve the
> > AsyncContext from the HttpServletRequest making the AsyncContext
> > complete call impossible.
> >
> > Activating the tomcat logging for AsyncContext
> > (org.apache.catalina.core.AsyncContextImpl.level = FINE) shows the
> > recycle method is called but not the complete method, what seems to
> > confirm my assumption. In a use case were the client waits for the
> > response, I can see both complete and recycle are called.
> >
> > My question is, what is the impact of the complete not being called
> > on the AsyncContext, is the socket cleaned up properly ?
>
> Tomcat version?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJX7CtcAAoJEBzwKT+lPKRYwekP/R1wirv0g7wJ3uR1Xk4mYIQo
> jPUYBirzVcewTWrDUpOe4BdXUBzgk7zDVrOsWU9PGlc0Prwik9YHeFWlG9ItxeEs
> 0ZJ0vJ1z6Od0KsxN6E8KobsE3rQu+td1Mh7d0g76zbHQKiLmrJNb8/hGuHVQr9Fd
> M597bec0JYiQSXU+8/SMErx/bdoA8HcApaeJpnl/RuCLfYwQ5ZSS/e0SCuSqMi1W
> bEU0vj0pBfK6h1WuweCRoBL5Shxa2XBpbc8nlPgb7IHNlQ15dwlD10nnuYDLb7DR
> VmOYEx2fmynZ/fOajfTsHoWUpoHjK47vMjtLUpIXARN8LY6tR2A2iUqJ6gXlM+QL
> gNRkucxkI3RSV3U7ipx7y5IJTglFC7uAyFlJpPLx8gLhGWSUz+q46lDr+332kF5x
> VU7rKLY/3RcSJG0ZLfIzPly5tz8wssMvwu94nI8lQb4SweEJDa6cT5Z8aUUTFaf6
> kjy34jSgsi6QyN+NK9WKapdDNzvIo1X18zK2CqfDSeyBsgprU62o1P8R/BxIiM9f
> YAnK98kPtmmKyJHcS7+fBngO1/TZvsdGlYj+cXcnCNi0Fnp50WKlHOPb6wcZo5q5
> lcpLkwj4izmdgW8rONjMDAZj3gal7OKw0WQ/srU6XIfUa1kgR0NAtb7YQGvHJA5g
> ljFdLIuRnMu+43OsbSKC
> =zrQ5
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: How do deal with 'sslv3 alert handshake failure'?

[Persson, Magnus (SE-TLX)]

Chris,

In tomcat 7.0.68 we added SSLv2Hello to allow our clients to connect but 
that do not work in versions after that. Maybe they changed the meaning 
of that protocol addition.

However, I changed the C++ POCO client to only use TLSv1.x and removed 
the SSLv2Hello protocol from tomcat config.
Works fine. I just need to change our reference implementation in python 
to stop using SSL23 too (which I do not know how to yet but that's 
another story).

I'm still learning the client and server parts of https and your 
valuable information is really helpful.
Thanks for your help,
Magnus

On 2016-09-28 17:48, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Magnus,
>
> On 9/28/16 2:20 AM, Persson, Magnus (SE-TLX) wrote:
>> The java servlet (in webapps folder) was written by a consultant
>> and I have only looked at parts of the source code and don't know
>> all that it does.
>>
>> The purpose is to give external integrators a way in to our
>> software through a REST API. We have made a reference client in
>> python that connects, creates a session and can send POST, GET,
>> DELETE, etc.
> Understood. The implementation of the servlet is largely irrelevant,
> since Tomcat is handling the TLS configuration.
>
>> This sample client will get this 'hello' ssl error with tomcat
>> versions greater than 7.0.68. I have also tested a client in c++
>> that uses the POCO library. Same hello error.
> So you are using a C++ client using POCO. It looks like POCO is using
> OpenSSL under the hood.
>
>> Since we have only specified the TLSv1.x protocols in the tomcat
>> config I assume the initial hello request is encapsulated in an
>> SSL2 frame by one of the TLSv1.x protocols.
> That's not the exact mechanics, but it's close enough. The problem is
> that the TLS handshake is not compatible with the SSLv2Hello-based
> one. So if the server supports only TLS and the client is expecting to
> be able to initiate an SSLv2Hello, then the client will get an error.
>
>> The purpose of adding TLSv2Hello was to allow this initial hello
>> request.
> Understood.
>
>> If the problem is the java servlet I'd like to correct it to not
>> encapsulate the hello request in an SSLv2/SSLv3 frame. Could this
>> be the problem or is it in the calling client?
> You can't fix the client's behavior by modifying the server.
>
> If you want to use only TLSv1 or later, then the best thing to do
> would be to update the client to only use TLS and not use SSL at all.
>
> On the other hand, SSLv2Hello *should* work from within Tomcat. With a
> fresh Tomcat, if you add "SSLv2Hello" to the sslEnabledProtocols list,
> can you make a connection from a client that supports TLSv1+ and uses
> a SSLv2Hello handshake?
>
> - -chris
>
>> On 2016-09-27 23:07, Christopher Schultz wrote: Magnus,
>>
>> On 9/27/16 10:29 AM, Persson, Magnus (SE-TLX) wrote:
> We started out with tomcat 7.0.35 and got that running with
> our REST servlet.
>
> When we upgraded to tomcat 7.0.63 we got this error when we
> tried to create a new session:
>
> { "message": "[Errno 1] _ssl.c:507: error:14077410:SSL
> routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
> failure" }
>> This is an error message from OpenSSL. Is this the client that is
>> choking, or the server?
>>
> Through Google we found out that we needed to add
> "SSLv2Hello" to the enabled protocols so we changed our
> connector in server.xml like this (only added SSLv2Hello):
>
>  maxThreads="150" scheme="https" secure="true"
> keystoreFile="${catalina.base}/conf/keystore"
> keystorePass="*" clientAuth="false" sslProtocol="TLS"
> sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1,SSLv2Hello"
> URIEncoding="UTF-8" />
>
> We upgraded to tomcat 7.0.68 and it works fine with above
> connector in server.xml
>> Do you absolutely need to accept SSLv2Hello-formatted handshakes?
>> Most of the web has abandoned SSLv3 and below at this point, so
>> SSLv2Hello should no longer be necessary.
>>
> When we upgraded to tomcat 7.0.70 we got the sslv3 error
> again even though we have SSLv2Hello in the enabled
> protocols:
>
> { "message": "[Errno 1] _ssl.c:507: error:14077410:SSL
> routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
> failure" }
>
> What do we need to change in the server.xml file to bypass
> the ssl3 error this time?
>> That depends upon where you are actually getting that error.
>>
>> -chris
>>> -
>>>
>>>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>>
>>> -
> - -
>>>
> This E-mail is PLAIN text, not support HTML, see instruction below on
> how to report SPAM.
>>>