Once I run an SSL server with puma:
bundle exec puma remote-webapp/config.ru -b 'ssl://0.0.0.0:8888?keystore=remote-webapp/keystore.jks&keystore-pass=123456'
And then try to use http instead on the https, the following error occur:
vendor/jruby/1.9/gems/puma-2.9.2-java/lib/puma/thread_pool.rb:56" java.lang.RuntimeException: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
The problem is then the particular thread would become a zombie and never got recycled. Is there anyway I could prevent this from happening?
Related
What exactly happens in Indy when a simple HTTPS request from a browser causes the debugger to break with this error:
Project PMS_COM.exe raised exception class EIdOSSLUnderlyingCryptoError with message 'Error accepting connection with SSL.
error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown'.
Some on the Internet say that this is a client certificate error, but there is no client certificate! There is only the server-side certificate.
But if I understood wrong and it is a client-side error, then why does it cause an exception on the server side?
Additionally I don't understand how to intercept such kind of errors. EIdOSSLUnderlyingCryptoError seems to happen somewhere in Indy with no chance to catch it in my code.
EIdOSSLUnderlyingCryptoError is an Indy exception wrapping an OpenSSL error message.
Per SSLv3 alert certificate unknown (4279556):
The SSL library sends an alert back to the system telling the certificate chain was invalid.
The message section that says "sslv3 alert certificate unknown" usually refers to the intermediate certificate in a chain of certificates. That certificate is expired, invalid or not trusted by one or more systems involved in the SSL/TLS communication.
In this case, the client (browser) is sending an alert to your server to abort the TLS handshake because your server certificate is invalid. That alert is triggering the EIdOSSLUnderlyingCryptoError exception within the server's code. The server will handle the error for you, by closing its end of the TCP connection that failed the handshake, and terminate/recycle the worker thread which owns that TCP socket.
If you want to catch the error, you can use the server's OnException event, which is triggered in the same thread that owns the TCP connection that failed the TLS handshake.
I'm running an nginx server with SSL enabled.
My protocol / cipher settings are fairly secure, and I've checked them at ssllabs.com, but --
-- since this is a web service which is called by http clients that I have no control over, I have concerns about compatibility.
To the point:
Is there a way to log SSL handshake failures as they happen (if they happen) in my nginx logs?
For example, I've got SSLv3 disabled, and if I try to "curl -3" (forcing SSlv3) to my server, then I get this:
NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP)
Cannot communicate securely with peer: no common encryption algorithm(s).
Closing connection 0 curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s).
I would like to log this type of error in server logs too, with the default nginx settings, there is nothing.
Enabling "debug" log level for the error log does what I want, will log SSL handshake errors -- but unfortunately it also logs too much other stuff, making the log too bloated, drowning out other potentially useful info.
You can use the info log level.
This is just to share my problem and solution to everyone.
I setup the plugin with the instructions from
https://wiki.jenkins-ci.org/display/JENKINS/Team+Foundation+Server+Plugin
First problem:
FATAL: com.microsoft.tfs.core.exceptions.TECoreException: Connection refused
java.lang.RuntimeException: com.microsoft.tfs.core.exceptions.TECoreException: Connection refused
Second problem:
FATAL: com.microsoft.tfs.core.exceptions.TECoreException: Unrecognized SSL message, plaintext connection?
java.lang.RuntimeException: com.microsoft.tfs.core.exceptions.TECoreException: Unrecognized SSL message, plaintext connection?
First problem:
FATAL: com.microsoft.tfs.core.exceptions.TECoreException: Connection refused
java.lang.RuntimeException: com.microsoft.tfs.core.exceptions.TECoreException: Connection refused
This is due to the firewall between my Linux Jenkins server and the Windows TFS server. I had Network team open the port 8080 and 443 from the Jenkins server to the TFS server.
That fixed the first problem.
Second problem:
FATAL: com.microsoft.tfs.core.exceptions.TECoreException: Unrecognized SSL message, plaintext connection?
java.lang.RuntimeException: com.microsoft.tfs.core.exceptions.TECoreException: Unrecognized SSL message, plaintext connection?
This is due to my incorrect URL to the TFS DefaultCollection
I used the https for "Server URL". This will demande a SSL certificate to be install on the Jenkins linux server.
https://swcosvctfs01.wco.int:8080/tfs/DefaultCollection/
After switching to http as below, the error went away, and Jenkins was able to checkout a copy of the TFS sourcecodes successfully.
http://swcosvctfs01.wco.int:8080/tfs/DefaultCollection/
I have recently switched over to HAProxy from AWS ELB. I am terminating SSL at the load balancer (HAProxy 1.5dev19).
Since switching, I keep getting some SSL connection errors in the HAProxy log (5-10% of the total number of requests). There's three types of errors repeating:
Connection closed during SSL handshake
Timeout during SSL handshake
SSL handshake failure (this one happens rarely)
I'm using a free StartSSL certificate, so my first thought was that some hosts are having trouble accepting this certificate, and I didn't see these errors in the past because ELB offers no logging. The only issue is that some hosts have do have successful connections eventually.
I can connect to the servers without any errors, so I'm not sure how to replicate these errors on my end.
This sounds like clients who are going away mid-handshake (TCP RST or timeout). This would be normal at some rate, but 5-10% sounds too high. It's possible it's a certificate issue; I'm not certain exactly how that presents to
Things that occur to me:
If negotiation is very slow, you'll have more clients drop off.
You may have underlying TCP problems which you weren't aware of until your new SSL endpoint proxy started reporting them.
Do you see individual hosts that sometimes succeed and sometimes fail? If so, this is unlikely to be a certificate issue. I'm not sure how connections get torn down when a user rejects an untrusted certificate.
You can use Wireshark on the HAProxy machine to capture SSL handshakes and parse them (you won't need to decrypt the sessions for handshake analysis, although you could since you have the server private key).
I had this happen as well. The following appeared first SSL handshake failure then after switching off option dontlognull we also got Timeout during SSL handshake in the haproxy logs.
At first, I made sure all the defaults timeouts were correct.
timeout connect 30s
timeout client 30s
timeout server 60s
Unfortunately, the issue was in the frontend section
There was a line with timeout client 60 which I only assume means 60ms instead of 60s.
It seems certain clients were slow to connect and were getting kicked out during the SSL handshake. Check your frontend for client timeouts.
How is your haproxy ssl frontend configured ?
For example I use the following to mitigate BEAST attacks :
bind X.X.X.X:443 ssl crt /etc/haproxy/ssl/XXXX.pem no-sslv3 ciphers RC4-SHA:AES128-SHA:AES256-SHA
But some clients seem to generate the same "SSL handshake failure" errors. I think it's because the configuration is too restrictive.
I was wondering if I can set an activemq broker with a ssl connection with the sole purpose of encryption (similar to HTTPS considering that the client does not check the certificate).
In that sense, I've tried seting up the broker to use ssl connection, set its keystore and on.
And on the client side, I tried using the sample code from fusesource as basis but without setting the client trust store (I would like the client to accept every certificate).
With that configuration, I could not connect the client and I got the following error message in the broker's log:
2013-05-06 15:25:32,848 | ERROR | Could not accept connection :
javax.net.ssl.SSLException: No available certificate or key
corresponds to the SSL cipher suites which are enabled. |
org.apache.activemq.broker.TransportConnector | ActiveMQ Transport
Server: ssl://0.0.0.0:61617?trace=true
Is this error really because the client has not added the broker certificate to its truststore? If so, is there a way so that the client accept the connection even without a truststore?
There was an error in my SSL configuration in the broker which caused that error message. I am not sure exactly what was wrong because I have re-done the whole configuration following this tutorial and got it to run the broker without errors.
In order to get the ssl encryption but no authentication, I basically had to set my ssl connection to <transportConnector name="ssl" uri="ssl://0.0.0.0:61617?trace=true?needClientAuth=false"/>
and to either
add the certificate directly to the JVM as in Resolving javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed Error?
or create a trust manager that accept all certificates on the client as in Setting trust store programatically in ActiveMQSslConnectionFactory seems to fail