I have created a Java application using Spring Security and I provided the ssl.server properties in application.properties. After enabling SSL handshake debug logs and verifying the connection I get a significant degrade in performance for two-way SSL.
Threads(users): 100
Request per thread: 100
1way SSL TPS: 110
2way SSL TPS: 25
noSSL (http): 120
Comparison between HTTP and one-way SSL is not that large as compared to one-way and two-way. I'm using Apache Tomcat.
I understand that there is an extra level of validation on server side. But is such a significant impact expected?
Related
I'm working on an academic project about TLS handshakes and i have captured some TLS traffic generated by multiple clients (google chrome, firefox...) and I want to see if for a given browser the client hello message will always be the same or no (I have removed the GREASE extensions because they are added in a random way to the client hello message and I omitted the SNI). I found that the same browser generate multiple client hello messages.
Is it normal to see such behavior or I'm doing something wrong?
A TLS handshake is done for each TCP connection involved in HTTPS and it is common that the browser uses multiple TCP connections in parallel. This is probably what you see. Multiple TLS handshakes within the same TCP connection are uncommon but might happen if a server requires a client certificate only for a specific path and thus triggers a renegotiation.
Reading mTLS from wikipedia
Is mTLS in microservices and the communication between services faster than if only TLS?
I mean if using only TLS the handshaking occurs each time a communication is being established between client & server.
If mTLS the handshaking only occurs once and the connection is kept to next communication/connection - and therefore faster?
Is this correct?
This is not correct.
Mutual authentication means that a client certificate is requested by the server additionally to the normal TLS handshake in order to authenticate the client. As for keeping the established TS connection open or using session resumption: this is possible for both "normal" TLS and TLS with mutual authentication.
I am using AWS ELB as entry point (in Proxy mode) to load balance among 2 HAProxy-es behind it from where traffic goes further to MQTT broker.
Those 2 HAProxies are responsible for client TLS termination (2 way TLS).
Certificates kind of work. I've tested on local setup between 2 servers. I've been able to publish with 2-way TLS, properly terminate it, and publish message to mqtt. Problem arise when moving everything to AWS.
I am using self signed root CA, intermediate CA, server certificate and client certificates. Using Elliptic Curve...
Problem might be due to a servers CN. I think it has to be the same as hostname connecting to with tools like mosquitto_pub.
Error that I get is TLS error, whith debug -> ssl handshake failure. Somehow I am not able to produce more verbose errors. Using openssl with s_client and debug for max debug output. Which produce me ssl handshake failure.
I would really appreciate any hint/suggestion.
Thanks in advance.
Tomaz
I solved this by using subjectAltName feature. I edited openssl.cnf and add new section [alt_names] and reference it later on in configuration. Under alt_names I added 1 DNS key, and 2 IPs. Found with man x509v3_config.
Best,
Tomaz
I have Local Webserver that configured to use SSL connection.
The question is - would there be any handshakes if i try to open https://localhost from any browser?
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys. But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
So, does handshake really happens, but on the upper OSI level? Or it doesnt happen at all, and there are no derive key creation?
Would there be any handshakes if i try to open https://localhost from any browser?
Yes,
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys.
No. It requires a certificate, and a premaster secret, and mutual negotiation of a master key from which session keys are derived. All this is irrelevant.
But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
Wireshark can't see loopback packets.
So, does handshake really happens
Yes.
but on the upper OSI level?
SSL happens in the application layer of the TCP model. The OSI model does not apply to TCP/IP. TCP/IP has its own model.
Or it doesn't happen at all
It does.
and there are no derive key creation?
There is creation of a pre-master secret, a master secret, and a session key. You seem to have some misconception of this process, but again it isn't relevant.
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.