You don’t know the private key used to sign the certificates. And if you don’t know it, it’s near to impossible to forge a signature that verifies with the corresponding public key.
How much load are we talking you think? Right now, I don’t really have a site, just a server. I have a very simple message saying future site of blah. Even when I get the site completely setup, I don’t expect a huge amount of traffic.
I’m more worried about the future. I can’t find the article, but recently, I came across an article. It talked about how this person broke some sort of encryption in something like 47 days. When the encryption was created, it would have taken a PC a million years or so to break it. Because of him breaking it, there was something like the SETI@Home stuff created to break all this older encryption or something using a bunch of PCs on the net and in the end, the project decrypted something like over 400 previously unbreakable encrypted stuff. That might not be 100% correct, but that’s how I remember it. Even though RSA 2048 is fairly safe now, I worry a lot about the future. I guess I’m being paranoid because in all reality, what would my server have that would be interesting to someone? RSA 4096 has been successfully decrypted, recently, using high powered microphones and listening to the noises from the CPU.
I guess what it comes down to is how secure do I want to be. It seems there’s always going to be pro’s and con’s. Better encryption, more CPU usage, stronger ciphers, less users who can view my site, etc. I just gotta find the right combination I guess that gives me strong security but still allows the majority of the people out there to view my site.
Thanks for helping explain all this to me guys! I really appreciate it!!!
This is something that I want. If I understand it correctly, HTTP Strict Transport Security (HSTS) makes it so users can only connect to my server via HTTPS. I have tried setting this up the best I could. I used mod rewrite rules, because I wanted everyone to use https since I got the SSL certs now. If someone goes to the unsecure website, it redirects them. I was thinking though, maybe I can just tell Apache not to listen on port 80 at all and if people go to http://mydomain.com, their browser will be smart enough to take them to the secure version? I’ll look into this more. Thanks for bringing this HSTS to my attention. I didn’t know about it before.
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 FS
If 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: !DSS
I 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:
There they also state the oldest clients, which are supported with the different configurations.
The rank is usually just determined by the server AFAIK…
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.
SSLLabs does not show bad cipher order:
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.
okay, lol didnt know that.