Re: Tomcat 8.5.23 Initialization PRNG/SSL

2017-10-30 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 10/27/17 10:55 AM, George S. wrote:
> I'm seeing some strange ssl errors. They're not reproducible 
> consistently, and I think they're because the PRNG is initializing
> after the Connector. Here's some log output:
> 
> 26-Oct-2017 17:04:08.380 INFO [main] 
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler 
> ["http-nio-8080"] 26-Oct-2017 17:04:08.429 INFO [main] 
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler 
> ["https-jsse-nio-443"] 26-Oct-2017 17:04:08.459 INFO [main] 
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler 
> ["ajp-nio-8009"] 26-Oct-2017 17:04:08.492 INFO [main] 
> org.apache.catalina.startup.Catalina.start Server startup in 56903
> ms 26-Oct-2017 17:05:16.364 WARNING [localhost-startStop-1] 
> org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom 
> Creation of SecureRandom instance for session ID generation using 
> [SHA1PRNG] took [118,978] milliseconds.
> 
> The exception is:
> 
> javax.net.ssl.SSLHandshakeException: Received fatal alert: 
> handshake_failure at
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown
> Source) at
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown
> Source) at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown
> Source) at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown
> Source) at 
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unk
nown
>
> 
Source)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown 
> Source) at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown 
> Source) at
> sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown
> Source) at 
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(
Unknown
>
> 
Source)
> at
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown
>
> 
Source)
> at 
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unkn
own
> Source)
> 
> 
> Has anyone else seen something like this? The app is making an
> internal SSL connection to another servlet. I don't know why they
> didn't use a RequestDispatcher and do .include(), but it's not my
> code.
> 
> Anyhow, am I right that the exception is probably related to the 
> connectors coming up before the PRNG?

These things are not connected -- this is just a coincidence. The
startup time you are seeing is for seeding the secure random-number
generator that produces session identifiers.

The error has to do with TLS cipher suite negotiations: there is
either a mismatch between protocols/cipher suites supported by both
client and server, or you are connecting to a service which requires a
client certificate and none has been provided.

I would scan the service to see what protocols/cipher suites are
actually supported and then check to see what the client has been
configured to support. My experience is that nobody ever bothers to
configure the client, and that the defaults are "connect to
anything!", so this does seem a little odd.

More information is necessary at this point.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln3M2cACgkQHPApP6U8
pFg78w//Y+hte1gG6rS6QC50pdvB1juLW6wD1JIhF/mrc6BPZYjlFhsS5LrJfHSM
Nb65m+9T6ic+LKnRhC8ftWQf4/BY2ZgFqOoWxnYydwa8TANSC43OhhskzKYq/mlR
4yRkQ0mi7tSB0EuF+z15v8y1myWz5RYQ/Eaj+XMjJn0p4mQHocU5QtZ1YxjMM15M
l4oXxAJeUjb6OSotTwv+GaiIfNDICL169pQcDZiUVTEOkONrhDWe0Nfv64u9QWRc
SzLx0zSSJleLuVBI8Uu7IvrB9MUw1HSAOh4bdpcw8b69HTK1Dw7lPA35ACmqzmm1
TbmltyCTLSBPHMb+R3Q71tUAfDTz+1DNPn97Ai5453l1Z/vmwqfo7vyr6tV3P2Zg
Td3XdL1wD3ICiR/z1tgubeGEHUwlljmnaARoHUU6lfLBj/wjVppw/8d3ODCr+kb1
biwNRKj/Tac7abRD/+K/ZUk1K0iPt5cOZBIRuvYr5FmuMQyxalLDikUM7UR5MWiW
mfT8tEubk85D36EfL0nljFGCOFzjpSEmZUC4RzSZTQT/UQjuriPPze8+NvsDIL/1
Jt3uy3fUk0plaPg/0cEs5dhw9dF4XxHsyYjTV/fQXI/HnMR2x8Ct5QmkynPNEnCu
NGTMEhMJL2cYN3fWbVcvUHfHn5uLQpMaUNj3uB3ArECikeDMgJM=
=YzS7
-END PGP SIGNATURE-

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

Re: [maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]

2017-10-30 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

(This turned out to be quite long. I honestly think it's worth reading.)

On 10/27/17 5:32 PM, André Warnier (tomcat) wrote:
> There seem to be a recrudescence of interventions on this list
> about SSL/HTTPS, and associated discussions about the usage of
> various randomness sources. I found this article interesting : 
> https://www.2uo.de/myths-about-urandom/

Thanks for posting this. I have a couple of comments.

1. The author provides very few references.
2. The author seems to be arguing /strongly/ in favor of universal use
of /dev/urandom, except the the time he briefly concedes that
long-lived keys probably ought to use /dev/random

So basically, he has expanded random(4) into a semi-didactic rant
about why people use "common knowledge" instead of real information.

I mentioned in a recent thread that maybe using haveged[1] on a
virtual machine might not be a good idea. My argument against goes
something like this:

1. Users should always have a choice between /dev/random and /dev/urando
m.
2. If you choose to use /dev/random for whatever reason (e.g. to
generate long-lived TLS/PGP/SSH keys), then you are expecting to get
the kind of entropy and randomness that device is documented to provide.
3. Virtual machines pull the wool over the eyes of the guest OS in
such a way to make all kinds of "hardware" events less random than one
would expect from bare-metal.
4. This tool therefore has the high potential to make /dev/random
behave like /dev/urandom, therefore this tool removes choice from the
user, the OS, and everything else. A user drawing from /dev/random is
expecting one type of randomness and getting another, and it's
possible that the user has no idea it's happening.

I would never recommend to anyone that they switch all of their uses
of /dev/urandom to /dev/random (not vice-versa). But I definitely
would recommend against anything that switches the semantics of
/dev/random to anything other than what it already does.

It's worth mentioning that there has been a lot of confusion over the
years as to what Java uses for its seeds -- at least the Sun/Oracle
flavor. For a time, the source was /dev/random, then /dev/urandom,
then a time where both /dev/random and /dev/urandom were somewhat
transparently aliased to one another so that if you wanted to get the
REAL one you wanted, you had to specify things like /dev/./urandom (or
/dev/./random) because the JVM would decide it knew better than you
did about where you wanted your entropy to come from.

As of this moment, the $JAVA_HOME/jre/lib/security/java.security file
on an arbitrary server I have available to me has the following line
of configuration in it:

securerandom.source=file:/dev/random

There is nothing in the comments surrounding that setting that
suggests anything other than /dev/random will be used.

Have a look at [2] which has references to the history of the whole
thing and a (reasonably) current statement about what's being used in
modern JVMs. I'm glad I read the Oracle Java 8 security update (which
I hadn't read before) ... I never knew that there was a new
SecureRandom.getInstanceStrong method to get the "Strongest source of
randomness" available to the JVM. Sadly, you can't select the provider
and algorithm -- while that choice might actually be counter-productive.

Remember that entropy is only required when seeding a random-number
generator such as java.util.Random or java.security.SecureRandom. Once
the algorithm has been seeded, no additional entropy is necessary for
the lifetime of PRNGs. Certain algorithms may choose to mix-in some
entropy at intervals during their lifetime, but it's not strictly
necessary.

IMHO, when it comes to generating long-lived keys, use of Java is not
necessary because there are better tools available. I don't know of
anyone who uses Java to generate PGP or SSH keys, for example. keytool
obviously does RSA and it the "tool of choice" when it comes to
generating new server keys for TLS with Java-based servers. I tend not
to use Java for and server-side TLS -- I use non-Java-based
reverse-proxies for that purpose -- and so use of keytool is
irrelevant for me. When using keytool, I highly suspect that
SecureRandom.getInstanceStrong is in use so using Java for such
high-security keys does in fact seem reasonable.

But for online use? Using /dev/urandom is certainly acceptable.
Unfortunately, it looks like Java's Random/SecureRandom classes don't
allow the client code to choose the source of randomness. That means
starting-up Tomcat will require a bit of entropy to come from
/dev/random -- at least on Java 8 and later -- and that may lead to
long startup times while the (blocking) device satisfies itself -- and
client code.

This presents a conundrum for system administrators who must then
decide amongst the following options for how to deal with long startup
times:

1. Use something like haveged
2. Switch the JVM from /dev/random to

Re: [maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]

2017-10-28 Thread tomcat 

On 28.10.2017 00:54, Bob Hall wrote:

  > On Friday, October 27, 2017, 2:32:50 PM PDT, André Warnier (tomcat) 
 wrote:
  >  >  > There seem to be a recrudescence of interventions on this list about 
SSL/HTTPS, and

associated discussions about the usage of various randomness sources.> I found 
this article interesting :> https://www.2uo.de/myths-about-urandom/


André, [OT] or not, thanks for adding a word to my vocabulary and for the 
article; recrudescence sounds better in French:
Google Translate




Well, Merriam-Webster defines it as follows :

Definition of recrudescence
:a new outbreak after a period of abatement or inactivity :renewal

a recrudescence of the symptoms

a recrudescence of guerrilla warfare


.. which is pretty much what I meant.

It may be however that the fact that I deal with a lot of medical literature in my 
professional life, is somewhat colo(u)ring my English vocabulary.

 ;-)


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

Re: [maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]

2017-10-27 Thread Bob Hall 
 > On Friday, October 27, 2017, 2:32:50 PM PDT, André Warnier (tomcat) 
 >  wrote:
 >  >  > There seem to be a recrudescence of interventions on this list about 
 >SSL/HTTPS, and 
> associated discussions about the usage of various randomness sources.> I 
> found this article interesting :> https://www.2uo.de/myths-about-urandom/

André, [OT] or not, thanks for adding a word to my vocabulary and for the 
article; recrudescence sounds better in French:
Google Translate


| 
| 
|  | 
Google Translate

Google's free service instantly translates words, phrases, and web pages 
between English and over 100 other lang...
 |

 |

 |


- Bob

[maybe OT] /dev/urandom [was : Re: Tomcat 8.5.23 Initialization PRNG/SSL]

2017-10-27 Thread tomcat 
There seem to be a recrudescence of interventions on this list about SSL/HTTPS, and 
associated discussions about the usage of various randomness sources.

I found this article interesting :
https://www.2uo.de/myths-about-urandom/

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

Re: Tomcat 8.5.23 Initialization PRNG/SSL

2017-10-27 Thread tomcat 

On 27.10.2017 16:55, George S. wrote:

I'm seeing some strange ssl errors. They're not reproducible consistently, and 
I think
they're because the PRNG is initializing after the Connector. Here's some log 
output:

26-Oct-2017 17:04:08.380 INFO [main] org.apache.coyote.AbstractProtocol.start 
Starting
ProtocolHandler ["http-nio-8080"]
26-Oct-2017 17:04:08.429 INFO [main] org.apache.coyote.AbstractProtocol.start 
Starting
ProtocolHandler ["https-jsse-nio-443"]
26-Oct-2017 17:04:08.459 INFO [main] org.apache.coyote.AbstractProtocol.start 
Starting
ProtocolHandler ["ajp-nio-8009"]
26-Oct-2017 17:04:08.492 INFO [main] org.apache.catalina.startup.Catalina.start 
Server
startup in 56903 ms
26-Oct-2017 17:05:16.364 WARNING [localhost-startStop-1]
org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of
SecureRandom instance for session ID generation using [SHA1PRNG] took [118,978] 
milliseconds.


If that means actually 118 thousand 978 milliseconds (just shy of 2 minutes), that looks 
like a lot.  According to the little I have been able to grab while perusing this list, 
that would indicate some serious difficulty for that host in generating sufficient entropy.

Maybe time to read the FAQ :
https://wiki.apache.org/tomcat/HowTo/FasterStartUp
Item 3.



The exception is:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown 
Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown 
Source)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown 
Source)

Has anyone else seen something like this? The app is making an internal SSL 
connection to
another servlet.


That does indeed not seem to make a lot of sense, unless this servlet could possibly be 
running on another server.


I don't know why they didn't use a RequestDispatcher and do .include(),

but it's not my code.

Anyhow, am I right that the exception is probably related to the connectors 
coming up
before the PRNG?

Tomcat is starting a Connector ["https-jsse-nio-443"], for which I suppose it also needs 
entropy.  Does the log say when that Connector is actually finished with starting up ?



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

Tomcat 8.5.23 Initialization PRNG/SSL

2017-10-27 Thread George S. 
I'm seeing some strange ssl errors. They're not reproducible 
consistently, and I think they're because the PRNG is initializing after 
the Connector. Here's some log output:


26-Oct-2017 17:04:08.380 INFO [main] org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["http-nio-8080"]
26-Oct-2017 17:04:08.429 INFO [main] org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["https-jsse-nio-443"]
26-Oct-2017 17:04:08.459 INFO [main] org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["ajp-nio-8009"]
26-Oct-2017 17:04:08.492 INFO [main] org.apache.catalina.startup.Catalina.start 
Server startup in 56903 ms
26-Oct-2017 17:05:16.364 WARNING [localhost-startStop-1] 
org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of 
SecureRandom instance for session ID generation using [SHA1PRNG] took [118,978] 
milliseconds.

The exception is:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown 
Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown 
Source)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown 
Source)

Has anyone else seen something like this? The app is making an internal 
SSL connection to another servlet. I don't know why they didn't use a 
RequestDispatcher and do .include(), but it's not my code.


Anyhow, am I right that the exception is probably related to the 
connectors coming up before the PRNG?


--
George S.
*MH Software, Inc.*
Voice: 303 438 9585
http://www.connectdaily.com