Added octopuspop.com

[luixxiul]

No description provided.

[fuglede]

This one is strange. From what I can tell, the site serves a broken certificate chain (cf. also Qualys), which means that it should not be included as it will cause potential breakage for Firefox users.

$ openssl s_client -connect ap.octopuspop.com:443 -showcerts
CONNECTED(00000003)
depth=0 OU = GT77422528, OU = See www.rapidssl.com/resources/cps (c)15, OU = Domain Control Validated - RapidSSL(R), CN = *.octopuspop.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = GT77422528, OU = See www.rapidssl.com/resources/cps (c)15, OU = Domain Control Validated - RapidSSL(R), CN = *.octopuspop.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = GT77422528, OU = See www.rapidssl.com/resources/cps (c)15, OU = Domain Control Validated - RapidSSL(R), CN = *.octopuspop.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/OU=GT77422528/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control Validated - RapidSSL(R)/CN=*.octopuspop.com
   i:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
-----BEGIN CERTIFICATE-----
MIIEtzCCA5+gAwIBAgIDAtXYMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMSAwHgYDVQQDExdSYXBpZFNTTCBTSEEy
NTYgQ0EgLSBHMzAeFw0xNTAzMDcxNDQ0NTZaFw0xNzAzMDkxOTQwMjNaMIGUMRMw
EQYDVQQLEwpHVDc3NDIyNTI4MTEwLwYDVQQLEyhTZWUgd3d3LnJhcGlkc3NsLmNv
bS9yZXNvdXJjZXMvY3BzIChjKTE1MS8wLQYDVQQLEyZEb21haW4gQ29udHJvbCBW
YWxpZGF0ZWQgLSBSYXBpZFNTTChSKTEZMBcGA1UEAwwQKi5vY3RvcHVzcG9wLmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKH4dT1aEmbsVILbNRdu
NTDl6MPjypoxEOtYEcJ81V4HAK+BAA+f8B0uvldkl2UJtUGOJ3yBt1tayw/WcpbF
LCm6UuEhUhwZiX77wlxKc+0tsW6EqbHISeUaJGQQs970aplcBRHwKnmheCT9Lllr
P3YwCBuuyfzrBcrSF2uX+SAMdHKkuH8RoAWLM8nOAf/w69kcthPffaH/2EQAx9zb
aORVHsw2tXHVRAXVWSQVPhVEh9epssbBtcAUTSkeR9irOaK2Zqji10igShWDFxzB
kgTtpSPsIwQ4Pu2w3gsWDnvh4lMFOGNTAxsINyG+OeHDB3QRAVhQnsyFNJri7xco
btkCAwEAAaOCAVwwggFYMB8GA1UdIwQYMBaAFMOc8/zTRgg0u85Gf6B8W/PiCMtZ
MFcGCCsGAQUFBwEBBEswSTAfBggrBgEFBQcwAYYTaHR0cDovL2d2LnN5bWNkLmNv
bTAmBggrBgEFBQcwAoYaaHR0cDovL2d2LnN5bWNiLmNvbS9ndi5jcnQwDgYDVR0P
AQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjArBgNVHREE
JDAighAqLm9jdG9wdXNwb3AuY29tgg5vY3RvcHVzcG9wLmNvbTArBgNVHR8EJDAi
MCCgHqAchhpodHRwOi8vZ3Yuc3ltY2IuY29tL2d2LmNybDAMBgNVHRMBAf8EAjAA
MEUGA1UdIAQ+MDwwOgYKYIZIAYb4RQEHNjAsMCoGCCsGAQUFBwIBFh5odHRwczov
L3d3dy5yYXBpZHNzbC5jb20vbGVnYWwwDQYJKoZIhvcNAQELBQADggEBAJ4vdfKZ
u8tHGShgKOQUJWGX+pr5DcaXOuTeD6KnA1cfDp2M7bv3+CQe7OpsFE0lbew4pKWZ
NZOYJhcYRRv9+d305Qz2a7YbqZjNyvfbpeywPAE4pWxBHPkmSGPa6Aj7bfV879cK
30/7FOYdzz9YLUewg3RQ4ym8CjwMHcqEYWjQW7MoR8H3QoKA58VQJb853ds8aRXY
v60vK6szlbYXvEo9bsBBltUpwbGjIPYFQebCUA9K+3N4J6fIG/BWinchlfrmy1fd
mAWlMm7muOB+xClMsaJ6rrEW1+0YaCB5Pw0JfZIp+X+SZnUjzhUoQwrM1os/UjRO
Mn+jN9j3yb/AM7Y=
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=GT77422528/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control Validated - RapidSSL(R)/CN=*.octopuspop.com
issuer=/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 1865 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 0B8C52FBBE5D2468696FC7A2EEB793817EAC8E886F9FCF254BCE722AB35106DF
    Session-ID-ctx: 
    Master-Key: E7A8D360CE03329ACB12E79F4B7BE57D6598E8E1FF94AFBB94007CE4B8594C0A302041CE53703A48412D7DFA89E7F65C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 21 f3 8e fb 48 6b 41 3b-c1 20 56 b0 6d 73 1b 90   !...HkA;. V.ms..
    0010 - df 87 30 ba 83 d3 f4 9c-46 a3 a3 b9 b5 7c 90 a0   ..0.....F....|..
    0020 - 1a 4e 98 db b8 22 67 61-a7 b1 6b f9 bc 45 3c be   .N..."ga..k..E<.
    0030 - b3 8f 2e 63 b2 4f e3 8e-cc 6c fd 97 a6 88 ae a3   ...c.O...l......
    0040 - c2 ee 89 da 77 22 fd 48-9f d0 0d ce 5c 1e 0a 05   ....w".H....\...
    0050 - 4f dd 2c 79 9e d2 a2 07-6d 4a a5 7d 93 d6 e3 9b   O.,y....mJ.}....
    0060 - 7f b1 a1 b1 ee 37 1d 1c-4f 25 56 a8 85 40 5a 32   .....7..O%V..@Z2
    0070 - b0 73 2c c6 72 d9 16 03-7b 01 04 37 87 db 73 e5   .s,.r...{..7..s.
    0080 - 63 e6 f4 e0 45 83 3c fa-8a 5d aa 57 18 5c 06 92   c...E.<..].W.\..
    0090 - 3b 50 5f 4f ca 0b e3 a6-52 22 ad 3d c9 b0 a7 f6   ;P_O....R".=....

    Start Time: 1471773136
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---

Nonetheless, it appears to pass the fetch test, but in fact, the main reason for including the fetch test was to detect broken certificate chains, so this is very strange.

$ ./fetch-test.sh rules/octopuspop.com.xml 
INFO Finished comparing http://admin.octopuspop.com/ -> https://admin.octopuspop.com/. Rulefile: rules/octopuspop.com.xml.
INFO Finished comparing http://ap.octopuspop.com/ -> https://ap.octopuspop.com/. Rulefile: rules/octopuspop.com.xml.
INFO Finished comparing http://octopuspop.com/ -> https://octopuspop.com/. Rulefile: rules/octopuspop.com.xml.
INFO Finished comparing http://www.octopuspop.com/ -> https://www.octopuspop.com/. Rulefile: rules/octopuspop.com.xml.
INFO Finished in 12.25 seconds. Loaded rulesets: 1, URL pairs: 4

@Hainish, was the fetch test logic changed recently in any way that could cause this to happen? If not, I suppose the issue lies with my own setup (tested on Debian Wheezy and Jessie), but I can not come up with any reason why that should be.

If I run pycurl directly, I do see the issue:

In [2]: c = pycurl.Curl()

In [3]: c.setopt(c.URL, 'https://octopuspop.com')

In [4]: c.perform()
---------------------------------------------------------------------------
error                                     Traceback (most recent call last)
<ipython-input-4-ca1d06f79dfb> in <module>()
----> 1 c.perform()

error: (60, 'SSL certificate problem: unable to get local issuer certificate')

[fuglede]

Ah, the reason must be that the fetch test CA repository does not reflect what is used by the two Debian versions.

In [5]: c.setopt(c.CAPATH, 'https-everywhere/test/rules/platform_certs/default/')  # The CA directory the fetch test uses

In [6]: c.perform()  # Now it works
<!DOCTYPE html>
...

Is this a bug in Debian? If not, the repository should be updated.

[luixxiul]

Though I don't get the error on Chrome, should this rule be disabled by default?

[fuglede]

If this is purely due to an issue with the CA collection in Debian (which would not be the first one), then the ruleset is fine, but it really depends on whether or not RapidSSL SHA256 CA - G3 is supposed to be trusted by default. If it is not, then the ruleset will cause issues for all Firefox users who have not cached the intermediate certificate by visiting another site where the chain is complete. It is different for Chrome users though, as they will automatically fill out the gaps in the chain.

Since Qualys also reports the chain as broken, I do imagine that there is an actual issue. In any case, I've contacted the webmasters to let them know about the problem; if they include the potentially missing certificate in the chain they serve, then everything is good for this ruleset (but not for our tests).

[jeremyn]

All four of the active targets work for me on Firefox on Windows 48.0.1.

[fuglede]

Now I didn't check how true this is, but in my experience, the Firefox certificate stores are generally platform independent, so I found this a little strange-sounding, and I tried in a fresh Firefox 48.0.1 profile (using firefox.exe -P) on Windows and found the issue to appear here as well:

[fuglede]

Of course this also means that what I pondered about Debian above is not correct, and that this is indeed an issue with our tests.

[jeremyn]

If I create a fresh Firefox profile with firefox -P, I get the warning. My understanding is also, like yours, that Firefox maintains its own certificates independent of the OS.

I compared the certificate store (Options > Advanced > Certificates > View Certificates) between my regular and the fresh profiles and do see that I have a RapidSSL SHA256 CA - G3 certificate associated with Software Security Device in my regular profile. The security devices can be found under Options > Advanced > Certificates > Security Devices.

From what I can tell this means that you are right and that somehow I got this intermediate certificate from somewhere. Do you have any idea where this came from?

[jeremyn]

I found this link very useful to understand this problem: https://wiki.mozilla.org/CA:FAQ .

I think I get it now. A website I visit prompts Firefox, behind the scenes without me knowing about it, to download an intermediate certificate if needed to check the actual certificate for the site. If the site is misconfigured, I won't get the intermediate certificate (see here). https://octopuspop.com is a site that is misconfigured that way. The reason it works on my regular profile is because I've previously visited some other site that also required the RapidSSL intermediate certificate that was configured correctly, so I already had the intermediate certificate installed.

Does that sound right?

[Hainish]

@jeremyn That's correct. If a valid intermediate is delivered when you visit site A, Firefox caches it in the Firefox certificate store. Then, when site B signed by the same intermediate delivers the certificate leaf node (but not the intermediate itself), Firefox will be able to build the entire cert chain because it has cached the intermediate previously with site A.

If site B was visited first, you'd get the browser warning, because Firefox would not have all the necessary certificates to build the chain.

[Hainish]

<aside>
An interesting quirk that happened as a result of intermediate cert caching: when the CA Browser Forum decided to sunset SHA-1, many CAs created new intermediates (since the old ones were signed with SHA-1), which then issued new certs to their clients. StartSSL went a different route: they simply re-signed their old intermediate certificates with SHA-256, without replacing them. Since the new intermediate was the same as the old one, they did not need to re-issue leaf certificates to their clients. But this is where some problems cropped up.

NSS, the TLS library used in Firefox and Chrome, builds the certificate chain in a non-deterministic way. Users that had previously visited sites which delivered the SHA-1 intermediate were getting that certificate cached, and then they would visit a site which delivered the intermediate signed with SHA-256. But since the same intermediate was already signed with SHA-1 and cached, users were getting browser warnings that indicated they were still offering a SHA-1 intermediate to users.
</aside>

[luixxiul]

So anyone please tell me if I have to change the ruleset or not?

[fuglede]

@Hainish's <aside />: That's an interesting consequence indeed!

@luixxiul: We can not include the ruleset right now, and unfortunately not much can be done to safe it, as every target host might cause issues for Firefox users. I told octopuspop about the issue, so with a bit of luck they will fix the site, and this ruleset becomes applicable.

[luixxiul]

@fuglede OK I see., thanks for doing that 👍

[jeremyn]

@Hainish Thanks for the information.

[jeremyn]

@fuglede Can we merge it in if @luixxiul disables it by default by changing the ruleset tag to this?

<ruleset name="octopuspop.com" default_off="https://github.com/EFForg/https-everywhere/pull/6102">

[fuglede]

@jeremyn Historically, at least, we have not introduced new default_off rulesets (cf. e.g. #954 (comment)).

[jeremyn]

@fuglede That makes sense, but I don't want to keep a pull request open forever with no clear next step. What should we do with it?

[fuglede]

Closing this for now. We can reopen it if they fix the site.

[jeremyn]

Thanks.

[fleugel]

We have missed to include intermediate CA to certificate setting, and it was fixed.
Thank you for yours advices.

$ openssl s_client -connect ap.octopuspop.com:443 -showcerts
---
Verify return code: 0 (ok)