ubill
Making SSL tests all pass for Phoenix + Let's Encrypt
Pre-info:
webserver : Cowboy only, not using nginx
My certs is from Let’s Encrypt (certbot)
Debian 8
Generated dh-param.pem file using openssl
1/
SSL Tester: https://www.htbridge.com/ssl
Right now, it can’t fulfill the “elliptic curves” criteria.
“The server supports elliptic curves that are considered weak.”
(currently I get A-, compared to capped at B- for the “do nothing” config)
Q. How do I pass in these values as in ssl — OTP 29.0.2 (ssl 11.7.2)
to my Phoenix config? (let’s say I am using dev.exs for this)
I am getting
[warn] Transport option {:eccs,
["sect571r1", "sect571k1", "secp521r1", "brainpoolP512r1", "sect409k1",
"sect409r1", "brainpoolP384r1", "secp384r1", "sect283k1", "sect283r1",
"brainpoolP256r1", "secp256k1", "secp256r1", "sect239k1", "sect233k1",
"sect233r1", "secp224k1", "secp224r1"]} unknown or invalid.
OR
[warn] Transport option {:honor_ecc_order, true} unknown or invalid.
[warn] Transport option {:eccs,
[:sect571r1, :sect571k1, :secp521r1, :brainpoolP512r1, :sect409k1, :sect409r1,
:brainpoolP384r1, :secp384r1, :sect283k1, :sect283r1, :brainpoolP256r1,
:secp256k1, :secp256r1, :sect239k1, :sect233k1, :sect233r1, :secp224k1,
:secp224r1]} unknown or invalid.
for the keys eccs and honor_ecc_order .
2/
SSL Tester: SSL Server Test (Powered by Qualys SSL Labs)
I am getting A- (improved from the basic grade of B for ‘do nothing’ config)
“The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-.”
Q. Could anyone give a clue on how to resolve that?
In short:
Although I do already get A- now, but I would like to know how to pass those options that I mentioned in order to get the satisfying “full compliance as per recommended” result. (For reference, I have achieved this before in my other tech stack’s webserver.)
The main point for me is to learn how to use Phoenix’s config file to pass the options I mentioned(through cowboy?) all the way to ssl options as stated as available in ssl — OTP 29.0.2 (ssl 11.7.2)
Marked As Solved
voltone
The warning messages are from Ranch, which is filtering out SSL options it does not recognize. Prior to version 1.3.0, Ranch only allowed whitelisted SSL options to be passed in. This was changed a few months ago to a blacklist: Blacklist listen options instead of whitelist · ninenines/ranch@b2b0996 · GitHub
Unfortunately, the latest version of Ranch on Hex appears to be 1.2.1, so you’d have to override the dependency in your mix.exs file and pull in 1.3.x from GitHub. I haven’t tried this myself.
Also Liked
ubill
Hi everyone here, many thanks for your help, and for your interest! ![]()
So, now I am Proud Asian Dad, as it is possible to get A+ for BOTH ssllabs and htbridge’s ssl tests:
This:
and this:
Ok, let me see if I can provide a step by step here as an article might take too long.
1/ Basically, googling for “let’s encrypt” may eventually bring you to “certbot” which following the instructions here, you ssh into your server and follow step by step.
This obtains free SSL certs and auto-renews them using cron jobs.
A word here, the scripts by default run as root, so you may want to explore further at this stage “automated but not as root”
But if you want to just get everything running quickly to try out, you can just follow the original instructions.
2/
Next is you put the settings in your config file (e.g. dev.exs or another)
I just put the settings here that get you the A+ result above…
Also left in the commented-out options, to show that I found that they were not necessary (but others could tell more about these if they know more about them)
config :hello_phoenix, HelloPhoenix.Endpoint,
http: [port: 80],
#force_ssl: [rewrite_on: [:x_forwarded_proto]],
url: [host: "asdf.qwer.com"],
force_ssl: [],
https: [port: 443,
otp_app: :hello_phoenix,
keyfile: "/PATH/TO/asdf.qwer.com/privkey.pem",
certfile: "/PATH/TO/asdf.qwer.com/cert.pem",
cacertfile: "/PATH/TO/asdf.qwer.com/chain.pem",
versions: [:"tlsv1.2", :"tlsv1.1", :"tlsv1"],
ciphers: ~w(
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
ECDH-ECDSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-SHA384
ECDH-ECDSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-GCM-SHA384
DHE-DSS-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-DSS-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
AES128-GCM-SHA256
AES128-SHA
DES-CBC3-SHA
)c,
dhfile: "/PATH/TO/projects/hello_phoenix/dh-params.pem",
secure_renegotiate: true,
reuse_sessions: true,
honor_cipher_order: true,
# http://erlang.org/doc/man/ssl.html#type-ssloption
### honor_ecc_order: true,
client_renegotiation: false,
eccs: [
:sect571r1, :sect571k1, :secp521r1, :brainpoolP512r1, :sect409k1,
:sect409r1, :brainpoolP384r1, :secp384r1, :sect283k1, :sect283r1,
:brainpoolP256r1, :secp256k1, :secp256r1, :sect239k1, :sect233k1,
:sect233r1, :secp224k1, :secp224r1
],
],
3/ As @voltone pointed out, if you used a wrong format for the ciphers, they will be silently ignored and the default suites used, that gets you A- or something else. If you use the one as shown here, they will be correct.
4/ So now running the tests on your server would give the same result.
‘OSCP Stapling’ item is not supported by the webserver, but that’s not quite important and there’s nothing you can do about it as well.
5/ I did not happen to try out (plug!) @voltone’s cipher_suites | Hex since I only got to know of it so late, but I expect that you will get the same good result in one step rather than doing it by hand as I did (looking up and copying the openssl aliases)
If you do try it, do let us know how it works!
voltone
Good, we’re getting closer, but we’re not there yet.
The message regarding forward secrecy from SSLLabs suggests you have cipher suites enabled that do not use a DH exchange. The :ciphers parameter in your configuration file does list only DH-enabled suites, but unfortunately Erlang’s :ssl module is silently ignoring the list and using its built-in defaults instead. I think you’ll find that the cipher list in the SSLLabs report does not match the list in your config file.
Erlang’s :ssl module expects cipher suite names to be passed in as charlists (not as Elixir strings, which are Erlang binaries; not sure why it’s silently ignoring binaries, though). And moreover, the names need to use OpenSSL naming conventions. So instead of…
ciphers: ~w(
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
# ...
)
…you’d have to use…
ciphers: ~w(
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
# ...
)c
(Note the c modifier at the end of the ~w sigil)
Shameless plug: you can use cipher_suites | Hex to select cipher suites using the OpenSSL filtering syntax often used in Apache/Nginx/… instead.
Regarding OCSP stapling: this is not currently supported by Erlang’s SSL/TLS implementation.
Last Post!
dom
Ah yes, indeed. I just happened to hit both problems at the same time because I was trying to configure RabbitMQ for mTLS.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex












