Disable SSLv3 (in favor of TLS) for the RPC client and server. #5434

1. 
   gmaxwell commented at 3:14 pm on December 6, 2014: contributor

   TLS is subject to downgrade attacks when SSLv3 is available, and SSLv3 has vulnerabilities.

   The popular solution is to disable SSLv3. On the web this breaks some tiny number of very old clients. While Bitcoin RPC shouldn’t be exposed to the open Internet, it also shouldn’t be exposed to really old SSL implementations, so it shouldn’t be a major issue for us to disable SSLv3.

   There is more information on the downgrade attacks and disabling SSLv3 at https://disablessl3.com/ .

2. Disable SSLv3 (in favor of TLS) for the RPC client and server.

   TLS is subject to downgrade attacks when SSLv3 is available, and
    SSLv3 has vulnerabilities.
   
   The popular solution is to disable SSLv3. On the web this breaks
    some tiny number of very old clients. While Bitcoin RPC shouldn't
    be exposed to the open Internet, it also shouldn't be exposed to
    really old SSL implementations, so it shouldn't be a major issue
    for us to disable SSLv3.
   
   There is more information on the downgrade attacks and disabling
    SSLv3 at https://disablessl3.com/ .

   683dc4009b
3. 
   gmaxwell commented at 3:15 pm on December 6, 2014: contributor

   I’d rather see the SSL support move out of the daemon entirely, but while it’s there it ought to be secure.

   This should be done for the payment request stuff too, but I’m not as familar with QNetwork stuff, and am not currently setup to test payment requests.

4. gmaxwell added this to the milestone 0.10.0 on Dec 6, 2014
5. 
   jgarzik commented at 3:24 pm on December 6, 2014: contributor

   ut ACK
6. 
   Diapolo commented at 5:18 pm on December 6, 2014: none

   What about the supported cipher suites string? I updated that once a while ago, we seem to use it for something, too ;).

7. 
   gmaxwell commented at 7:10 pm on December 6, 2014: contributor

   Shouldn’t be updated for this. SSL protocol is controlled by the setting this patch changes, not the cipher suites string. Confusingly, you can set something like SSLvX in the suites string … but thats basically filtering ciphers based on what SSL version they were introduced with. … if you remove all the SSLv3 ciphers it also limits you to TLS 1.2 only, because TLS 1 introduced no ciphers. I didn’t do this because we do want to support third party RPC clients, which might just be TLS 1 or not support the 1.2 ciphersuites.
8. 
   gmaxwell commented at 12:23 pm on December 7, 2014: contributor

   Someone who normally uses this should also test it.
9. 
   aalness commented at 7:54 pm on December 7, 2014: contributor

   ACK. Tested on OSX 10.9.2. Also confirmed with openssl s_client/s_server that the client/server would not downgrade to SSLv3.
10. 
    gmaxwell commented at 9:36 pm on December 7, 2014: contributor

    @aalness Because of TLSv1.2. (unless I’m missing something there).
11. 
    aalness commented at 0:11 am on December 8, 2014: contributor

    @gmaxwell Yup. It was bugging me so I verified with Wireshark. If the method is ssl::context::tlsv1 OpenSSL won’t upgrade to TLSv1.2. Seems like odd behavior to me but shrug.
12. 
    laanwj commented at 9:14 am on December 8, 2014: member

    I remember @theuni disabling SSLv3 in the depends build, but defense in depth is good, and this also fixes it for people who build from source against a OpenSSL that still has it. utACK commithash 683dc4009b2b01699e672f8150c28e2ebe0aae19 (signature)
13. laanwj merged this on Dec 8, 2014
14. laanwj closed this on Dec 8, 2014

    ---

15. laanwj referenced this in commit 4b5b263ac0 on Dec 8, 2014
16. MarcoFalke locked this on Sep 8, 2021

Contributors
gmaxwell jgarzik Diapolo aalness laanwj

Milestone
0.10.0