HOWTO: A+ with all 100%'s on SSL Labs test using apache2.4 (READ WARNINGS)


#3

Yes, it’s a very restrictive setup. I was just listing what it takes to get all 100%'s on their test.

I see Googlebot/2.1 in my logs now on the SSL site, so it seems to support this configuration, but I agree MANY other clients won’t be able to negotiate.


#4

i’d warn folks as 100% in all tests can be dangerous to a site’s livelihood and traffic…

the proper way is to fully analyse all sites traffic and browser breakdown for sites you intend to deploy SSL on and make sure your web site traffic won’t be adversely affected…

Google Analytics can give you a proper breakdown of web browser and browser version and OS stats i.e. for one of my sites broken down by WinXP vs non-WinXP and then by specific browsers and their versions


Let's Encrypt certificates do not work on XP in IE8 or Chrome
#5

Agreed. I’ve linked to your post in a warning header. Thanks for the Analytics reference too, that’s a great idea.


#6

Hi, at least there is one gap in your setup you should read a little bit more about “Public-Key-Pins”.
You pin only one key and for very long time frame. All documentations mention that you should
ALWAYS add an backup key that is offline that can be used in replacement in case of another
ssl gau like heartbeat.


#7

Thanks… that’s left from me hastily trying things to get to 100. I updated it, but please check it for correctness. I also threw another disclaimer at the top that I’m an idiot, instructing people to not follow me.


#8

Some (important) general notes about the first post…

  1. Do not pin your private key!
  2. HPKP is risky. You should always understand what it is, how it works and what effects this has/can have before using it on your (productional) server.
  3. @tlussnig is right: You have to add a backup key. Otherwise this disables the added security by HPKP, so it’s just useless. You should use dev.ssllabs.com to test this with the latest version of SSLLabs test as this has integrated more tests of headers like HSTS and HPKP. Edit: The SSLLabs version with extended HPKP test is now stable and accessible at ssllabs.com.
  4. Currently there is an important thing you should know when using HPKP with Let’s Encrypt, which can - in the worst case - break your whole site and prevent users from accessing your site. More information here:
    HTTP Public Key Pinning (HPKP)

The most important thing: Do not follow guides just to get 100% of something. Think about what you actual do at your server!

Here are some good resources for reading about HPKP:

Additionally here you get a bunch of tools for HPKP by @ScottHelme, especially the analyse tool.


#9

Some notes about your site after testing it:

  1. You have included a report-uri directive in your HPKP header. (http://130.117.188.81/pkp-report) I don’t know whether you actually know what it is used for, but currently it does nothing and is insecure.
    1.1. It does nothing because the page at http://130.117.188.81/pkp-report returns a 404 error, so it does not seem to exist.
    1.2. It is insecure, because it does not use HTTPS. And I also don’t know why you use the IP address there. That’s not necessary and obviously prevents using HTTPS there.
    You should use a normal HTTPS address, because the attack scenario HPKP wants to protect against includes an attacker monitoring all traffic from a clients device. WIthout HTTPS he can just tamper the reports.
    You may say that sending this reports could also trigger an (HPKP) error, but this is good and by design. If the clients follow the specification they should try to send such reports later again.
  2. To be even more secure you could enable OCSP.
  3. Currently your server seems to accept non-existent TLS versions including TLS 1.3, which is the next TLS version which you likely want to support if it’s ready.

#10
  1. I fully know that i did currently not have an servlet behind the reporting url. But 404 are logged so you checked it last nicht 0:30 and 0:50.
  2. If there is something to report than possible there is an attacker between the client and my host:
    a) DNS-Spoofing
    b) Man in the middle
    So the client have no secure connection to the host. But http: to the IP is not affected by key pinning / hsts and allow the client to at least try to send the data without an SSL error.
  3. OCSP stapling is enabled and OCSP,CRL also.
  4. No if only accept TLSv1.2 it is TLS version intolerance to 1.3 and that is marked orange because i the near future server should support it.

#11

This is great commentary and I have learned a lot from the comments, but I feel I should remove this post as it’s dangerous and misleading at this point.


#12

No. I think it is very insightful. Please leave it up.

Personally I think that any client that does not support encryption require to get an A+ grade is broken, out of date, and deserves to be locked out, blocked, left out in the cold, etc. Keep up to date or get left behind I say.


#13

You don’t need a restrictive setup to get an A+, see https://www.ssllabs.com/ssltest/analyze.html?d=kelunik.com.


#14

Right, but when you go for 100’s it gets very restrictive. The basic apache setup gets you an A+ iirc.


#15

Basic setup with Mozilla Intermediate and HSTS, yes.


#16

I’m curious about the 4096-bit RSA key and Diffie-Hellman parameters. In most current keylength recommendations those would be considered disproportionate to the security levels of other parts of the system. Would the SSL Labs site give an A+ for a 2048-bit RSA key and 2048-bit DH parameters? Do you have to go all the way to 4096 and 4096 for the A+?

I believe @kelunik’s setup is showing an A+ right now with 2048 and 2048.


#17

Yes, 2048 and 2048 is enough for an A+.


#18

[quote=“kelunik, post:17, topic:2436, full:true”]
Yes, 2048 and 2048 is enough for an A+.
[/quote] Yup it is, provided optimal cipher preferences the difference between A and A+ is usually whether HSTS is enabled or not


#19

I also enabled mod_spdy losely following https://xuri.me/2015/02/25/enabling-spdy-and-hsts-on-apache.html and CHACHA20-POLY1305 with https://github.com/PeterMosmans/openssl/tree/1.0.2-chacha… getting a little nuts over here.


#20

Hi,

after your comments of hpkp report i change the handling.
Now if gets logged and return an
405 “Method not Allowed” for anything other than POST
201 “Created” if there was an POST call.


#21

or check out https://report-uri.io/


#22

@eva2000 nice page but since HPKP violations are not common. I would like to see two more topic on this page.

  1. An Test how some Page behave if they receive an HPKP report.
  2. An Tutorial how someone can test that his browser reports error for his domain.