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

Did I claimed something else?

The German guide is also a bit more comprehensive - that’s why I linked it mainly.

In this case you’ve already lost if you use their devices, because obviously they could have added many root certificates or modified other things, where TLS cannot protect you.
A much better situation is if you use your own device in their WLAN: If a connection fails, because they intercept it the HPKP report may be triggered and sent. If this does not succeed the Browser can still try it again - at some point you maybe use another Wi-Fi network.

Hi, i setup an test domain with invalid pin’s. In the firefox console log i get the warning “Public-Key-Pins: The site specified a header that did not include a matching pin.” But the lock stay green and there is no report submited.
Not the action i expected at all. (In have the Self Created CA in my Truststore).

https://hpkp-fail.suche.org/

about:config
security.cert_pinning.process_headers_from_non_builtin_roots = true
security.cert_pinning.enforcement_level = 2

1 Like

Obviously this is out of scope of this thread and not related to Let’s Encrypt, but just a short answer:
In the sites I linked to you can see how it should work. You can also test it here: https://pinning-test.badssl.com/ although this is only about preloaded pins and only works in the current Chrome/Chromium versions.
So to get back to your case: Maybe you loaded a site which loaded other assets from a domain with HPKP which are blocked as it is shown in the console.
The connection to https://hpkp-fail.suche.org/ currently fails. (timeout error, so not cause by HTTPS/HPKP)

I made an easy way to get the DH Parameter patched certificate updated. Put a small shell script on

Hi, i think this is misleading. Because i think currently only RSA Certificates can be used with letsencrypt.

"create a certificate with those dh params"
DHE in the ciphersuites is used for Key Exchange with forward security.

A browser must not cache or apply a HPKP policy if there is not at least 1 valid pin in the policy. If it did this, you would have immediately blocked any and all access to the domain in question, which is what the requirement is there to protect against, accidentally causing a DoS.

To create my demo subdomain, https://hpkp.scotthelme.co.uk, I created a HPKP policy on http://scotthelme.co.uk that contains the includeSubdomains directive. This policy will then apply to all subdomains but the policy does not include a valid pin for the certificate on the hpkp subdomain, causing the HPKP error.

I hope that helps.

2 Likes

@rugk : Thanks for the tip with “TLS extension intolerance” i fixed my server that he now accept 1.3 too.
@ScottHelme : If i go first to “hpkp” and later to the main domain and than back to “hpkp” i did not receive
any warning. After closing firefox and go to main domain first i receive an warning. But i can not see
traffic to report-uri.io i my browser log or browser DNS information.
If i got you correct it i set an lifetime of one year for the pin the browser would cache the information
across the sessions ? Is this anywhere described ?

I’ve just checked Firefox and it’s also acting a little buggy for me. Once you have visited the main domain then you should have the policy and cache it to be applied. Does it work in Chrome? (Firefox doesn’t report on HPKP violations yet).

1 Like

The issue is that it should not accept 1.3…
Because TLS v1.3 is not even standardized yet so the web server does quite sure not support it.

1 Like

Hi, i fully understand it. If an client connect with SSL Version TLSv1.0 Handshake Version TLSv1.3 the server response with TLSv1.2.

That’s the correct way.

OK now i also Updated to 4 times 100%
The decission is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA with server side mitigated. (4*100)
or TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (one of them required for firefox).
Personal i think 100,100,100,90 with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 would be more secure.
And it would be good if the rating would also show this.

So here is a more appropriate place for such an request: https://community.qualys.com/community/ssllabs :smile:

1 Like

@ScottHelme has a nice article for nginx users to check the TLS protocol and cipher usage https://scotthelme.co.uk/monitoring-http-2-usage-in-the-wild/ and in comments section links to how to do the same for Apache http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#envvars

so could be useful to profile your visitor’s and their clients

I followed Scott’s example and profiled my forums HTTP/TLS protocol and SSL cipher usage too https://community.centminmod.com/threads/http-tls-protocol-and-ssl-cipher-usage-statistics-logging.4985/ :slight_smile:

This + web browser profiling HOWTO: A+ with all 100%'s on SSL Labs test using apache2.4 (READ WARNINGS) would help folks decide on the cipher preferences they want to support based on their visitor and visitors’ clients profiles.

1 Like

In order to get 100% in the Key Exchange bar on my server running Apache 2.4.7 and OpenSSL 1.0.1f, I had to also specify a curve with a 384-bit field strength, as the default curve secp256r1 has less equivalent strength than 4096bit RSA.

To see what 384 bit curves you support, run openssl ecparam -list_curves | grep 384; you’ll probably see secp384r1. In which case you can get the output of openssl ecparam -name secp384r1 and put it in your leaf cert’s pubic file between the cert and the dhparams (I’m not 100% sure you have to put it between, or if it could also work after the dhparams). Alternatively, you can put the output of that command in its own file and specify it in your Apache config with SSLOpenSSLConfCmd ECDHParameters; similar to SSLOpenSSLConfCmd DHParameters, I believe it only works with Apache 2.4.8 or later with Openssl 1.0.2 or later.

  1. You should not use any curve greater or equal 384
  2. Since the cert file will updated on regular basis i would not recommend to put the parameter there.
    p.s. It is also possible to Fake the result (https://www.ssllabs.com/ssltest/analyze.html?d=suche.org)

and using that faking it might be easy enough to clear that mega challenge of conquering both testers.

  1. Nope the challenge was extra with the hint without tricks. Because it should show the users that it is not possible
    to always reach different goals at the same time.
  2. SSL-Labs does an handshake simulation that i can match via fingerprinting to one individual browser.
    On the the side the pci test scan for ciphersuites like the rating part of ssla labs does and look at the found
    cipher suites. So ist may not even possible (except ip based) to reach both 100% marks.
    -> My trick is neither IP based nor test specific like saying the n’th connection from this server get other config.

well I just thought that a server must connect (i.e. send a clienthello) to see what you can do) and with that I thought you could serve specific to the tests