Debian

Duplicity does not verify SSL certificate prior to connecting

Bug #1314234 reported by Eric Christensen
284
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Duplicity
Fix Released
Undecided
Unassigned
Debian
Fix Released
Unknown

Bug Description

While doing some testing using deja-dup I noticed that the SSL certificate that Amazon S3 was providing wasn't correct.

$ 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

The Amazon certificate is a wildcard cert for *.s3.amazonaws.com. Unfortunately the domain duplicity was connecting to was s3-1-w.amazonaws.com. Duplicity should have verified that the certificate was valid for the domain it was connected to.

CVE References

Revision history for this message
Eric Christensen (sparks) wrote :

Hi, it's been three weeks. Can anyone comment on this?

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote : Re: [Bug 1314234] Re: Duplicity does not verify SSL certificate prior to connecting

I am not entirely sure what the answer should be. If we 'fail' the
connection and refuse to accept a mis-applied wildcard, we'll probably fail
most connections (there are a bunch of systems in a bunch of companies set
up like this). We could 'warn' in this case, but that just creates more
noise.

My best guess would be to accept if the domain matches, 'amazonaws.com',
and fail if it does not. Tricky.

On Tue, May 20, 2014 at 8:11 AM, Eric Christensen <
<email address hidden>> wrote:

> Hi, it's been three weeks. Can anyone comment on this?
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/1314234
>
> Title:
> Duplicity does not verify SSL certificate prior to connecting
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
>
> Bug description:
> While doing some testing using deja-dup I noticed that the SSL
> certificate that Amazon S3 was providing wasn't correct.
>
> $ 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
>
> The Amazon certificate is a wildcard cert for *.s3.amazonaws.com.
> Unfortunately the domain duplicity was connecting to was
> s3-1-w.amazonaws.com. Duplicity should have verified that the
> certificate was valid for the domain it was connected to.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/1314234/+subscriptions
>

Revision history for this message
Eric Christensen (sparks) wrote :

I think that, at the very least, a warning should come up. Otherwise, failing to fail the connection means that someone could launch a MITM attack easily.

Revision history for this message
Eric Christensen (sparks) wrote :

I should note that I've already contacted Amazon about the certificate error.

Revision history for this message
Vincent Danen (vdanen) wrote :
Download full text (5.8 KiB)

Is it not possible to have a configurable option? Sounds like the best compromise. Do the right thing by default, and allow people who are in certain situations to configure it to allow for the wrong behavior. That way if there is ever a problem, it was because they chose the more insecure default.

Otherwise you're stuck building white- and black-lists which is just annoying for everyone.

--
Vincent Danen / Red Hat Security Response Team

> On May 20, 2014, at 3:35 PM, Kenneth Loafman <email address hidden> wrote:
>
> I am not entirely sure what the answer should be. If we 'fail' the
> connection and refuse to accept a mis-applied wildcard, we'll probably fail
> most connections (there are a bunch of systems in a bunch of companies set
> up like this). We could 'warn' in this case, but that just creates more
> noise.
>
> My best guess would be to accept if the domain matches, 'amazonaws.com',
> and fail if it does not. Tricky.
>
>
> On Tue, May 20, 2014 at 8:11 AM, Eric Christensen <
> <email address hidden>> wrote:
>
>> Hi, it's been three weeks. Can anyone comment on this?
>>
>> --
>> You received this bug notification because you are subscribed to
>> Duplicity.
>> https://bugs.launchpad.net/bugs/1314234
>>
>> Title:
>> Duplicity does not verify SSL certificate prior to connecting
>>
>> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
>> New
>>
>> Bug description:
>> While doing some testing using deja-dup I noticed that the SSL
>> certificate that Amazon S3 was providing wasn't correct.
>>
>> $ 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
>>
>> The Amazon certifi...

Read more...

Revision history for this message
Vincent Danen (vdanen) wrote :

Anything further on this? It's been a few weeks and we'd like to make this public so we're not sitting on it forever. If there is no objection, we would like to open our bug on June 11, 2014 at about 16:00 UTC, although ideally we'd like to do so with some guidance for a fix or patch.

Thanks.

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :
Download full text (7.2 KiB)

I found an error in the way you are running the openssl command, it should
include the -CAcert option. See the man page for s_client. Running with
that yields a clean verification:

ken@stealth:~$ openssl s_client -CApath /etc/ssl/certs -connect
s3-1-w.amazonaws.com:443
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
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFQTCCBCmgAwIBAgIQGHBX7tZDXzmvfSkeROrx7DANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwHhcNMTQwNDA5
MDAwMDAwWhcNMTUwNDA5MjM1OTU5WjBrMQswCQYDVQQGEwJVUzETMBEGA1UECBMK
V2FzaGluZ3RvbjEQMA4GA1UEBxQHU2VhdHRsZTEYMBYGA1UEChQPQW1hem9uLmNv
bSBJbmMuMRswGQYDVQQDFBIqLnMzLmFtYXpvbmF3cy5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCyIdaCeebmUg7oowAEkJOGAkE9KA7f/Kpsbexn
sD0v/W2Hbq7Kmys8LD9bs6RX4YNIr/Cx0i4gQlymmVXy/OhgrvSpl/lbmHzFXF30
UF2/L6NWkbkca2QbmolYBjYHngblx/gRQw6XGSui2Ql8q6W5IOz1EyHUZOhcr5W8
x76JtY4r5/uav+2WO9pgtGEL4aROQfE7R/399OvkUCabcTvaG9N0TMBLTdB/mWyD
GlnHSwWl67lH1HPr429iz/2cPP7l3eq1V1PNq25w5JCV2kySmq5d0XKt4cy5mMh/
Og2vcwyj31u8B4fzyGWxQAXLs10wWF9xdVNHrJwoBD9jeiWDAgMBAAGjggGUMIIB
kDAJBgNVHRMEAjAAMEMGA1UdIAQ8MDowOAYKYIZIAYb4RQEHNjAqMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMEUGA1UdHwQ+MDwwOqA4
oDaGNGh0dHA6Ly9TVlJTZWN1cmUtRzMtY3JsLnZlcmlzaWduLmNvbS9TVlJTZWN1
cmVHMy5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQY
MBaAFA1EXBZTRMGCfh0gqyX0AWPYvnmlMHYGCCsGAQUFBwEBBGowaDAkBggrBgEF
BQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMEAGCCsGAQUFBzAChjRodHRw
Oi8vU1ZSU2VjdXJlLUczLWFpYS52ZXJpc2lnbi5jb20vU1ZSU2VjdXJlRzMuY2Vy
MA4GA1UdDwEB/wQEAwIFoDAvBgNVHREEKDAmghIqLnMzLmFtYXpvbmF3cy5jb22C
EHMz...

Read more...

Revision history for this message
edso (ed.so) wrote :
Download full text (7.7 KiB)

true if he got
 Verify return code: 20 (unable to get local issuer certificate)

else his certificates might just be outdated ;) .. ede/duply.net

On 03.06.2014 20:00, Kenneth Loafman wrote:
> I found an error in the way you are running the openssl command, it should
> include the -CAcert option. See the man page for s_client. Running with
> that yields a clean verification:
>
> ken@stealth:~$ openssl s_client -CApath /etc/ssl/certs -connect
> s3-1-w.amazonaws.com:443
> 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
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
> MIIFQTCCBCmgAwIBAgIQGHBX7tZDXzmvfSkeROrx7DANBgkqhkiG9w0BAQUFADCB
> tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
> ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
> YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMm
> VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwHhcNMTQwNDA5
> MDAwMDAwWhcNMTUwNDA5MjM1OTU5WjBrMQswCQYDVQQGEwJVUzETMBEGA1UECBMK
> V2FzaGluZ3RvbjEQMA4GA1UEBxQHU2VhdHRsZTEYMBYGA1UEChQPQW1hem9uLmNv
> bSBJbmMuMRswGQYDVQQDFBIqLnMzLmFtYXpvbmF3cy5jb20wggEiMA0GCSqGSIb3
> DQEBAQUAA4IBDwAwggEKAoIBAQCyIdaCeebmUg7oowAEkJOGAkE9KA7f/Kpsbexn
> sD0v/W2Hbq7Kmys8LD9bs6RX4YNIr/Cx0i4gQlymmVXy/OhgrvSpl/lbmHzFXF30
> UF2/L6NWkbkca2QbmolYBjYHngblx/gRQw6XGSui2Ql8q6W5IOz1EyHUZOhcr5W8
> x76JtY4r5/uav+2WO9pgtGEL4aROQfE7R/399OvkUCabcTvaG9N0TMBLTdB/mWyD
> GlnHSwWl67lH1HPr429iz/2cPP7l3eq1V1PNq25w5JCV2kySmq5d0XKt4cy5mMh/
> Og2vcwyj31u8B4fzyGWxQAXLs10wWF9xdVNHrJwoBD9jeiWDAgMBAAGjggGUMIIB
> kDAJBgNVHRMEAjAAMEMGA1UdIAQ8MDowOAYKYIZIAYb4RQEHNjAqMCgGCCsGAQUF
> BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMEUGA1UdHwQ+MDwwOqA4
> oDaGNGh0dHA6Ly9TVlJTZWN1cmUtRzMtY3JsLnZlcmlzaWduLmNvbS9TVlJTZWN1
> cmVHMy5jcmwwHQYDVR0lBB...

Read more...

Revision history for this message
Eric Christensen (sparks) wrote :

I wasn't using openssl s_client for anything other than to show you that the certificate isn't valid for the domain. When Duplicity connects to Amazon it is connecting to the domain s3-1-w.amazonaws.com which is using a certificate for *.s3.amazonaws.com. SSLLabs also complains about this mismatch (https://www.ssllabs.com/ssltest/analyze.html?d=s3-1-w.amazonaws.com).

Duplicity is *not* complaining about this certificate error meaning that it's not validating the certificate at all.

Revision history for this message
edso (ed.so) wrote :

On 03.06.2014 21:51, Eric Christensen wrote:
> I wasn't using openssl s_client for anything other than to show you that
> the certificate isn't valid for the domain. When Duplicity connects to
> Amazon it is connecting to the domain s3-1-w.amazonaws.com which is
> using a certificate for *.s3.amazonaws.com. SSLLabs also complains
> about this mismatch
> (https://www.ssllabs.com/ssltest/analyze.html?d=s3-1-w.amazonaws.com).
>
> Duplicity is *not* complaining about this certificate error meaning that
> it's not validating the certificate at all.
>

i am not familiar with the details of how the validation needs to be done. but actually we probably don't need to - we use boto to access s3 and
 https://groups.google.com/forum/#!topic/boto-users/6k_KA9UeQ5E
suggests it has an option for that. which only needs to be enabled.

we should probably tie the switching of that option to the command line parameters i created for webdavs '--ssl-cacert-file' & '--ssl-no-check-certificate'.

Eric: would you mind implementing this for the recent 0.7 devel branch?

..ede/duply.net

Revision history for this message
Vincent Danen (vdanen) wrote :

Any progress? Or can we file our public bug regarding this? I had meant to do so on Wednesday, but forgot about it. I don't think there's a reason to keep this embargoed. If I hear nothing in the next few hours I'll go ahead and file our bug. It would be nice if we could link to a patch though.

Thanks.

Revision history for this message
Vincent Danen (vdanen) wrote :

This issue has been assigned CVE-2014-3495.

Revision history for this message
Vincent Danen (vdanen) wrote :

I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1109999 as a public bug.

Kenneth Loafman (kenneth-loafman)
information type: Private Security → Public Security
Bug Watch Updater (bug-watch-updater)
Changed in debian:
status: Unknown → Confirmed
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Has there been any progress on this issue?

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

No, no progress as yet.

On Mon, May 25, 2015 at 10:54 AM, Marc Deslauriers <
<email address hidden>> wrote:

> Has there been any progress on this issue?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1314234
>
> Title:
> Duplicity does not verify SSL certificate prior to connecting
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
> Status in Debian:
> Confirmed
>
> Bug description:
> While doing some testing using deja-dup I noticed that the SSL
> certificate that Amazon S3 was providing wasn't correct.
>
> $ 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
>
> The Amazon certificate is a wildcard cert for *.s3.amazonaws.com.
> Unfortunately the domain duplicity was connecting to was
> s3-1-w.amazonaws.com. Duplicity should have verified that the
> certificate was valid for the domain it was connected to.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/1314234/+subscriptions
>

Revision history for this message
edso (ed.so) wrote :

Marc,

feel free to volunteer. comment #10 might get you started ..ede/duply.net

On 26.05.2015 15:02, Kenneth Loafman wrote:
> No, no progress as yet.
>
>
> On Mon, May 25, 2015 at 10:54 AM, Marc Deslauriers <
> <email address hidden>> wrote:
>
>> Has there been any progress on this issue?
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1314234
>>
>> Title:
>> Duplicity does not verify SSL certificate prior to connecting
>>
>> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
>> New
>> Status in Debian:
>> Confirmed
>>
>> Bug description:
>> While doing some testing using deja-dup I noticed that the SSL
>> certificate that Amazon S3 was providing wasn't correct.
>>
>> $ 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
>>
>> The Amazon certificate is a wildcard cert for *.s3.amazonaws.com.
>> Unfortunately the domain duplicity was connecting to was
>> s3-1-w.amazonaws.com. Duplicity should have verified that the
>> certificate was valid for the domain it was connected to.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/duplicity/+bug/1314234/+subscriptions
>>
>

Revision history for this message
az (az-debian) wrote :

according to the boto release notes for 2.6.0 (http://docs.pythonboto.org/en/latest/releasenotes/v2.6.0.html), boto now defaults to certificate verification ON instead of opt-in.

i think that's pretty much it, given that boto is now at version 2.45 or so.

if that is considered not certain enough, then i think all that's necessary would be to
adjust duplicity/backends/_boto_single.py where storage_uri.connect() is called and change those
calls so that the validate_certs option is explicitely given.

Revision history for this message
edso (ed.so) wrote :

On 26.01.2017 04:47, az wrote:
> according to the boto release notes for 2.6.0
> (http://docs.pythonboto.org/en/latest/releasenotes/v2.6.0.html), boto
> now defaults to certificate verification ON instead of opt-in.
>
> i think that's pretty much it, given that boto is now at version 2.45 or
> so.

stable is now boto3, any reason why we still stick with the boto2 ?

> if that is considered not certain enough, then i think all that's necessary would be to
> adjust duplicity/backends/_boto_single.py where storage_uri.connect() is called and change those
> calls so that the validate_certs option is explicitely given.
>

nack.. that would break backward compatibility. we could do that for 0.8.x though..

..ede/duply.net

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :
Download full text (3.6 KiB)

We will need to update to boto3 eventually, I think. Boto just hit 2.45
just a month ago. What's unclear is when validate_certs became a
parameter, and whether it has maintained that name throughout. A simple
fix would be to add a kwargs parameter for anything above a set version,
but then we'd have to add another argument to duplicity to allow the user
to turn it off in some situations.

...Ken

On Thu, Jan 26, 2017 at 4:07 AM, edso <email address hidden> wrote:

> On 26.01.2017 04:47, az wrote:
> > according to the boto release notes for 2.6.0
> > (http://docs.pythonboto.org/en/latest/releasenotes/v2.6.0.html), boto
> > now defaults to certificate verification ON instead of opt-in.
> >
> > i think that's pretty much it, given that boto is now at version 2.45 or
> > so.
>
> stable is now boto3, any reason why we still stick with the boto2 ?
>
> > if that is considered not certain enough, then i think all that's
> necessary would be to
> > adjust duplicity/backends/_boto_single.py where storage_uri.connect()
> is called and change those
> > calls so that the validate_certs option is explicitely given.
> >
>
> nack.. that would break backward compatibility. we could do that for
> 0.8.x though..
>
> ..ede/duply.net
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1314234
>
> Title:
> Duplicity does not verify SSL certificate prior to connecting
>
> Status in Duplicity:
> New
> Status in Debian:
> Confirmed
>
> Bug description:
> While doing some testing using deja-dup I noticed that the SSL
> certificate that Amazon S3 was providing wasn't correct.
>
> $ 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
> ...

Read more...

Bug Watch Updater (bug-watch-updater)
Changed in debian:
status: Confirmed → Fix Released
Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

I am guessing that this was fixed ages ago for the reasons given in the Debian tracker:
"according to the release notes for boto 2.6.0
at http://docs.pythonboto.org/en/latest/releasenotes/v2.6.0.html
boto's default is now to enable certificate verification.
(before that version it was opt-in, which duplicity never got around to.)

given this and the versions of python-boto in stable and unstable
(2.34 and newer) there's nothing left to do for duplicity
and i'm therefore closing this bug.
"

It would be great if there is someone with the right setup to confirm, though, so that we can close this off.

Kenneth Loafman (kenneth-loafman)
Changed in duplicity:
status: New → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.