First... I don't understand why and how it gets the "additional" cert from server (.tntcode.net), that is a default hostname I set for that server, and I think this additional cert might cause some of the problems:
The problems I have are:
Android 2.3.7 No SNI, Incorrect certificate because this client doesn't support SNI,
RSA 2048 (SHA256) | TLS 1.0 | TLS_RSA_WITH_AES_128_CBC_SHA
I agree with SSL Labs in this case. The point of SNI is to allow a server to choose the appropriate certificate from among several certificates that it may possess in order to answer incoming TLS connections to a shared server. Without SNI, the server doesnât know which site the client wanted to connect to, so it returns the default certificate.
That is the expected behavior of any site, and in the case of your site, the default certificate covers only *.tntcode.net, which doesnât match www.apkfiles.com.
The only way to fix this to support non-SNI-capable clients is to add multiple names onto the same certificate. Letâs Encrypt will allow you to do this; you could, for example, get a single certificate for both *.tntcode.net and *.apkfiles.com. If that certificate is presented as the default one, clients will realize that itâs valid for either domain, and not reject it.
Otherwise, you will need to give up support for non-SNI-aware clients, or use a separate IP address for each domain name.
Hi @schoen
It doesnât make sense to me, maybe you can explain differently, but ⌠when someone opens the site, nginx will serve the specified cert based on the hostname requested, as I set in nginx.conf, it returns the *.apkfiles.com cert for www.apkfiles.com , I still donât get how server would end up including the .tntcode.net one. And why that one and not another domain cert I have on the server (around 4) ?
Is it related to how data would be encrypted and server needs to route traffic without seeing the traffic contents ? Or I am way off already ?
There are two ways the hostname is requested in HTTPS: once at the TLS level (using SNI), and once at the HTTP level (using the Host: header). Virtual hosts or virtual servers are typically selected by web server applications using the Host: header, but certificates have to be selected using the SNI method because they have to match in older to complete the TLS negotiation.
That means that when there is no SNI, there is no "hostname requested" from the point of view of choosing a certificate. Although the server could rely on the Host: header in HTTP, that comes later on, and the TLS negotiation is already supposed to be complete before that happens!
Yes, that's also a pretty reasonable way to think about it. In order for the encryption to get set up, the virtual host has to be selected. It would be possible for a load balancer to use the SNI field to route different TLS connections to different backends, even without being able to see inside the encryption (for example, without possessing the private keys for the different services). However, in that case the load balancer wouldn't know what to do if an inbound connection with no SNI arrived.
So in the end, for an old client like âAndroid 2.3.7â (without SNI) I have no way to setup a https connection without a dedicated IP ? I still donât get it 100%
(I mean without the load balancer complications).
Is that why I remember some years ago you needed a dedicated IP for https ? Because clients were older ?
I forgot about multiple domains in same cert. I might do that too eventually.
Are there performance issues if I use same cert for around 30 different domains ? I assume cert string is same size (e.g download time), but clients would need to go trough a longer domain list to process/verify ?
Clients are also doing a whole bunch of cryptography; scanning a list of 30 domains isnât a big deal.
Certificates do contain the complete list of names covered. They do take time to download. But there are already kilobytes of overhead; adding one more probably isnât a big deal.
Ssllabs shows more secure ciphers in mozilla's version, but I assume server is a bit faster with less protocols, is that correct ?
Both these get same overall score and the Handshake Simulation test shows same results for different clients.
Thanks for the help guys
Not really relevant.
Speed (as in throughput and encryption/decryption) happens after negotiation.
Negotiation is generally controlled by the server preference order (top down or left to right if you are reading through the ssl_ciphers list).
The client need only parse it once (happens almost instantly) to "understand" which cipher to use.
To "test" your actual encryption/decryption speeds (which can vary from CPUs and O/Ses), you may need to run some openssl tests or download a large file from a client while forcing the use of different ciphers.
Got it. Thanks.
I was more worried about userâs performance, because on main site, most of them are on mobile phones and some of them should be older generation.
That is an insecure cipher list. CBC3 & 3DES have vulnerabilities that can be exploited. I also suggest killing all protocols below TLSv1.2. If you have to go as low as TLSv1.0, force this Cipher list:
I also want to point out that the test you are looking at is a simulated client/browser on an android 2.3.7 device, which is super old and several years past EOL. SNI was not a thing back then, and the error disappears with cloudflare if you use their SSL front-end service because they handle the browser encryption while your LE cert on the server will handle your server to cloudflare encryption.
So then you need to ask yourself, will you really have anyone accessing your site from an old android 2.3.7 device? More than likely not, so you donât need to worry about being able to support that client.
EDIT:
Let me clarify that Android is currently on 9 (Pie). 2.3.7 is not older, itâs ancient⌠. 3.x was Honeycomb, 4.0 was Ice Cream Sandwich, 4.2.2 JellyBean, 4.4 KitKat, 5.0 Lollipop, 6.0 Marshmallow, 7.0 Nougat, 8.0 Oreo.
It's hard to know which ciphers you use in this case because it's dependent on what visitors to your site try to negotiate with you. You could log that if you wanted to, but web servers normally don't log it by default. Mozilla is trying to make informed recommendations here based on security and compatibility considerations.
Totally agreed; especially in this case, anyone assuming that he actually knows what he is using [or not] is likely suffering form hallucinations.
But the statement is there for all that may read it (not just for him).
And it should be read to imply (contrapositive?):
âif you are certain about what you donât use, then turn those things offâ.
Or ridiculously reduced to: % !{use} : #
[conciseness sometimes complicates understandability]
I agree with that for computing in general, but I think it's unlikely that most people have informed individual opinions about ciphersuite selection at the moment, so most people have ended up following some authority on this pointâwhich isn't surprising because the landscape is so complicated.
The landscape is complicated because it is constantly changing. BEAST, POODLE & all its variations, CBC & 3DES zero-length vulnerabilities. Then you have IDS/IPS/WAF services that canât decrypt DH Ciphers, which limits you to 2 ciphers on TLSv1.2, and kills your browser compatibility unless you allow for TLSv1.0 & 1.1. Itâs definitely an area you need to have the patience to keep up with.
