<div dir="ltr"><br><div class="gmail_extra">Hi!<br><br></div><div class="gmail_extra"><div class="gmail_quote">2016-04-27 19:10 GMT+02:00 Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 04/27, Ingela Andin wrote:<br>
</span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We promise to be backwards compatible, not bug compatible.<br>
</blockquote>
<br></span>
I feel I should expand on that.<br>
<br>
Right now I have a list of specified SSL ciphers of the form:<br>
<br>
{ecdhe_ecdsa,aes_256_gcm,null,sha384}<br>
{ecdhe_ecdsa,aes_256_cbc,sha384,sha384}<br>
{ecdhe_ecdsa,aes_256_cbc,sha384},<br>
...<br>
{rsa,aes_256_gcm,null,sha384}<br>
{rsa,aes_256_gcm,null}<br>
{rsa,aes_256_cbc,sha256}<br>
<br>
You'll note that this list contains some ciphers that may or may not contain the GCM component in them. The thing I'm doing then is that because GCM support is dependent upon platform and OpenSSL version (i.e.  OSX by default does not ship with support for ecliptic curve + GCM mode, but does so on other versions), I will do either of the following things:<br>
<br>
1. Filter out ciphersuites not supported by the VM<br></blockquote><div><br></div><div>There is an internal  function in ssl that does that  ssl_cipher:filter_suites/1. It is used when the cipher option is not set to filter out suites from the default value that may not have support by crypto.<br></div><div>I am thinking maybe it should be applied to the users option too and return an error if it becomes empty, or maybe make a new API function?!<br></div><div><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. Mandate some ciphersuites to be supported for the app to boot.<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Prior to 18.3, the easiest way to do that was to compare the values<br>
given to what was being returned by `ssl:cipher_suites()': if the value was in, it was supported by the VM.<br>
<br>
Starting with 18.3, this started breaking since I had to check for 4-tuple support in there to make sure that a 3-tuple wasn't being passed where a 4-tuple was required and the opposite. THat's okay, I can work with that.<br>
<br>
The problem is that starting with 18.3.2, `ssl:cipher_suites()' returns a 4-tuple whether this format is actually being supported or not.<br>
<br>
This means that there isn't any way for me to configure things in any dynamic manner whatsoever, since I cannot validate which ciphersuite configurations are supported by using the functionality of the SSL library itself.<br>
<br>
See the following example in 18.3:<br>
<br>
1> ssl:listen(0, [{ciphers,ssl:cipher_suites()}]).<br>
{ok,{sslsocket,...}}<br>
<br>
And see the same result in 18.3.2:<br>
<br>
1> ssl:listen(0, [{ciphers,ssl:cipher_suites()}]).<br>
{error,{options,{ciphers,[{ecdhe_ecdsa,aes_256_gcm,null,<br>
                                      sha384},<br>
                         ...<br>
                         {ecdh_rsa,...},<br>
                         {...}|...]}}}<br>
<br>
Maybe there's something I'm not getting, but it seems to me that the bug is in 18.3.2, not in the other versions.<br></blockquote><div><br><br></div><div>Humm there seems to be something missing from this patch that is present in master.  I will look into if your PR if it is<br></div><div>the correct fix  or what would be. Of course we will fix this.<br></div><div><br><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br></div><div><br><br><br> </div></div><br></div></div>