From ${URL} : Eric Christensen of Red Hat Product Security reported [1] that Duplicity did not handle wildcard certificates properly. If Duplicity were to connect to a remote host that used a wildcard certificate, and the hostname does not match the wildcard, it would still consider the connection valid. The example of which is provided: $ openssl s_client -connect s3-1-w.amazonaws.com:443 -crlf CONNECTED(00000003) depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority verify return:1 depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify return:1 depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)10, CN = VeriSign Class 3 Secure Server CA - G3 verify return:1 depth=0 C = US, ST = Washington, L = Seattle, O = Amazon.com Inc., CN = *.s3.amazonaws.com verify return:1 --- Certificate chain 0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=*.s3.amazonaws.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3 i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority In this instance, the domain being connected to is not *.s3.amazonaws.com, but s3-1-w.amazonaws.com. There is currently no upstream fix. [1] https://bugs.launchpad.net/duplicity/+bug/1314234 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
The reported issue is that a wildcard SSL certificate, which is issued to an owner of a particular domain, is not valid. As such, if you are willing to accept such a certificate then you are trusting the owner of that domain in it's entirety. If we really broke this down, someone owning amazonaws.com should answer all DNS requests for that particular domain. If you are not willing to trust this then hardening is the proper approach. Furthermore, the original reporter in the upstream bug did not properly validate against the CA with the proper OpenSSL option of -CACert.
