I was forgetting about the public key. Just pretending I'm the same signing authority (ie, using the same name) isn't enough. Even if my server provides a public key that claims I'm the signing authority, the store won't have the right information and they'll know my site can't be trusted. This makes sense. I think I'm finally wrapping my head around this stuff!
I GOT THE A+!!! Oh man, you guys are the freaking greatest!!! I setup the HSTS and now I get the A+ rating!!! Thereās still some stuff I gotta figure out how to fix though. A lot of the clients listed in the Handshake Simulation got the R next to it. As you probably know, that R denotes a reference browser or client, with which we expect better effective security.
I think whatās that is saying is it connected using a certain cipher but maybe my server should have provided a better cipher. Hereās an example:
Chrome 51 / Win 7 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FSIf Iām right, then that means I gotta figure out a better cipher list I think for Apache. This is what I currently got (and I have my server set to honor the order).
ECDH+AESGCM:
DH+AESGCM:
ECDH+AES256:
DH+AES256:
ECDH+AES128:
DH+AES:
ECDH+3DES:
DH+3DES:
RSA+AESGCM:
RSA+AES:
RSA+3DES:
!aNULL:
!MD5:
!DSSI put those new lines there so itās easier to read. I wonder if thatās the problem though and where I could get a good list to use. Maybe mine isnāt in the right order or has weaker ciphers.
I think I might know whatās going on. From what Iāve been reading, Iād have to throw out the 128-bit and maybe even the 256-bit elliptic curve for my ECDHE suites and use just the 384-bit ones.
Personally Iād avoid going purely by the SSLLabs ranking, it only matches the reference state of the browsers (Which can be changed by things like attackers/AVs, which are basically the same these daysā¦), and has a few issues (Like it doesnāt consider GCM to be a stronger mode than CBC, so can rank CBC suites above GCM ones, which is plain wrong)
Rather, Iād sit down and draw up a list of what browsers/clients you want to support and their capabilities, then derive your settings from that (Like the current list youāre using includes a bunch of non-PFS suites, which isnāt a problem if the browser always connects to the site with the most secure settings, but end-user issues can prevent that, and theyāll use older ciphers that SSLLabs wonāt pick up). That also involves things like what protocol versions they can talk, and what cipher suites can be used (If you want AES-GCM or ChaCha20, you need TLS 1.2 to use them, since anything that uses TLS 1.1 can only use AES-CBC at best)
Using my personal site as an example, I only care about the latest browser releases (IE11 is the oldest browser that I care about), so my cipher list only includes 4 suites total (AES-128-GCM, AES-256-GCM, ChaCha20, and AES-256-CBC for IE11 on Windows 7/8), every one using ECHDE (So a non-PFS connection canāt be negotiated), and since those suites require TLS 1.2 I donāt have to support anything older.
Thank you. I've been using a plethora of tools for my server but so far, for the SSL stuff, I've only tried SSL Labs. Can you recommend some other sites or tools that might be of interest for the SSL tests or any other tests I might want to run?
I wanted to support back to IE8, just in case there was any XP users (hopefully not) still out there. I'm not sure what's the lowest versions of Chrome / Firefox I should work on supporting. Is there a list of their capabilities? I'd love to see the various clients, their versions and what's the maximum ciphers / protocols they support. Right now, I have TLSv1.0, TLSv1.1 and TLSv1.2 enabled for the protocols and all else off I believe. I thought if any client supported TLSv1.1, it probably supported TLSv1.2 as well. But I kept all three TLS versions enabled because when I disabled TLSv1.0, I saw on SSL Labs a lot of clients couldn't connect. Thanks!
Yes, that's what it says, but "except better security" just means this browser should be able to use a good cipher and if this browser fails to do so, there is something wrong with your config. So I think these browsers are just the "reference browsers" you should support.
As for your example the cipher is all right.
No, better don't do this. 128bit has some advantages (excluding performance) in some cases.
I'd always recommend Mozilla's config generator:
https://mozilla.github.io/server-side-tls/ssl-config-generator/
There they also state the oldest clients, which are supported with the different configurations.
The rank is usually just determined by the server AFAIK...
See this:
wait a sec. he's talking about 128bit ELLIPTIC curves, and 128 elliptic is bad.
128 AES is okay, but elliptic, nope, seriously not.
In this case, yes, but you cannot use 128bit EC anyway as no browser supports it.
thatās true as well, but probably SSL check sites would throw a bunch of warnings.
I donāt even know if it is possible to specify 128bit ECs. And as the server got an A+ I doubt such a EC curve is used on the server.
Yeah, if you're enforcing server order then that's what it shows, but if you've got that disabled then it sorts by the bit value, so AES-256-CBC gets put ahead of AES-128-GCM.
I don't think it is, TLS has a predefined list of supported curves, and it only goes as low as 163bits
Okay, I've reported it.
@rugk is CBC that bad?
In TLS it is generally used in a secure way, but CBC is certainly worse than GCM, because GCM is authenticated encryption.
This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken.
https://www.imperialviolet.org/2014/12/08/poodleagain.html
SSLLabs does not show bad cipher order:
https://community.qualys.com/thread/15785
but arent the TLS functions already authenticated by a bunch of different hash functions?
AES GCM is simplified iirc just CBC + auth as far as I have read it.
I personally rather keep it modular because you dont need to kick everything but you can replace just the dead parts.
CBC is inherently hard to implement without exposing some padding oracle that can be used in an attack (see cryptographic doom principle). AEAD ciphers such as GCM donāt have that problem.
1 Like
okay, lol didnt know that.
I am enforcing server order. I don't really understand the ciphers that much. I'm not very good with cryptography. If my order is incorrect, could someone please suggest the best order? This is what I currently have:
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
In that order.
There's a lot going around here so it might take a bit for me to respond. Sorry for the delays.
Iād go with the intermediate compatibility configuration Mozilla provide, itās a good mix of security and compatibility (Gets you IE7 on XP SP3 I think)
2 Likes
My server is official broke now. I donāt know what I did. cPanel updated and some how the experimental Apache jail got enabled. Disabling that seemed to fix the problem. Then I got some warnings from cPanel how the Apache jail should be enabled. I sent cPanel a message, but when I go to my site, all I get is an error message:
This site canāt provide a secure connection
jetbbs.com sent an invalid response.
Try:
Reloading the page
Learn more about this problem.
ERR_SSL_PROTOCOL_ERROR
Iāve even went back to the default cPanel SSL cipher list. The protocols are still the default ones, -SSLv2 -SSLv3. Not sure what I did wrong how to fix this.
I have two IP addresses for my server and I was playing around with assigning the domain both IP addresses. I thought perhaps this would break my site though so I undid that. But still, I get the error message. If I go to the site using the IP address instead of the domain name, it loads as expected but I get the red X through the https sign. Iām using Google Chrome and I went into Incognito mode to make sure it was loading a fresh page and not cached results.
From reading stuff on the internet, people say this could be caused by having the SSL cert installed incorrectly, so Iām coming here first. Any thoughts?
The apache error log shows nothing about my home IP address, however, the access log shows this every time I try to connect:
my_home_ip - - [20/Jul/2016:15:37:29 -0400] "\x16\x03\x01" 400 1993
my_home_ip - - [20/Jul/2016:15:37:29 -0400] "\x16\x03\x01" 400 1993
my_home_ip - - [20/Jul/2016:15:37:29 -0400] "\x16\x03\x01" 400 1993
my_home_ip - - [20/Jul/2016:15:37:29 -0400] "\x16\x03\x01" 400 1993
my_home_ip - - [20/Jul/2016:15:38:22 -0400] "\x16\x03\x01" 400 1993
my_home_ip - - [20/Jul/2016:15:38:22 -0400] "\x16\x03\x01" 400 1993
my_home_ip - - [20/Jul/2016:15:38:22 -0400] "\x16\x03\x01" 400 1993
my_home_ip - - [20/Jul/2016:15:38:22 -0400] "\x16\x03\x01" 400 1993For security reasons, Iāve replaced my home IP address with the words my_home_ip. Iāve tried searching google for those \x16\x03\x01 but I donāt get anything. Iām assuming this is because of the slashes. Anyone have any idea what I did wrong?
Thanks!