New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let's Encrypt intermediate not accepted by Chrome and IE8 on Windows XP #1660

Closed
intgr opened this Issue Dec 2, 2015 · 77 comments

Comments

Projects
None yet
@intgr

intgr commented Dec 2, 2015

I know and I've heard all the caveats that Windows XP is unsupported, etc etc. But there's still a significant user base left on Windows XP.

If Let's Encrypt certificates are officially known to be broken on Windows XP, that's fine. But there should be a clear official statement of that fact somewhere (e.g. Let's Encrypt FAQ), so everyone who has this issue, knows that they're SoL.

Screenshots of Chrome on Windows XP with certificate details:

letsencrypt-xp1
letsencrypt-xp2

@aaronmehar

This comment has been minimized.

Show comment
Hide comment
@aaronmehar

aaronmehar Dec 2, 2015

It wouldn't be the certificate that is not compatible but the implementation of it, as the procurer of the certificate it would your job to ensure its works for your user base, for XP users, they should upgrade to 7-10 or use a proper OS, such as Fedora or Ubuntu. If they insist on using crap, you will need an IP per certificate, letsencrypt have chosen to use SNI (good for them), although SNI should work on Chrome6 in XP.. what service pack are you running?

aaronmehar commented Dec 2, 2015

It wouldn't be the certificate that is not compatible but the implementation of it, as the procurer of the certificate it would your job to ensure its works for your user base, for XP users, they should upgrade to 7-10 or use a proper OS, such as Fedora or Ubuntu. If they insist on using crap, you will need an IP per certificate, letsencrypt have chosen to use SNI (good for them), although SNI should work on Chrome6 in XP.. what service pack are you running?

@intgr

This comment has been minimized.

Show comment
Hide comment
@intgr

intgr Dec 2, 2015

If they insist on using crap, you will need an IP per certificate, letsencrypt have chosen to use SNI (good for them),

This is not an SNI issue, as you can see from the screenshots. I am being provided with the correct helloworld.letsencrypt.org certificate. It's just not verifying.

The screenshots are from my Windows XP virtual machine, that has SP3 and all available Windows updates applied. It's running Chrome version 47.0.2526.73 m.

intgr commented Dec 2, 2015

If they insist on using crap, you will need an IP per certificate, letsencrypt have chosen to use SNI (good for them),

This is not an SNI issue, as you can see from the screenshots. I am being provided with the correct helloworld.letsencrypt.org certificate. It's just not verifying.

The screenshots are from my Windows XP virtual machine, that has SP3 and all available Windows updates applied. It's running Chrome version 47.0.2526.73 m.

@intgr

This comment has been minimized.

Show comment
Hide comment
@intgr

intgr Dec 2, 2015

If anyone wants to reproduce this issue, Windows XP virtual machines are available from Microsoft: https://dev.windows.com/en-us/microsoft-edge/tools/vms/linux/

aaronmehar is right that you can't test IE8 on helloworld.letsencrypt.org due to lack of SNI, but you can install Chrome or try other websites in IE8 like https://paymail.pm/

intgr commented Dec 2, 2015

If anyone wants to reproduce this issue, Windows XP virtual machines are available from Microsoft: https://dev.windows.com/en-us/microsoft-edge/tools/vms/linux/

aaronmehar is right that you can't test IE8 on helloworld.letsencrypt.org due to lack of SNI, but you can install Chrome or try other websites in IE8 like https://paymail.pm/

@intgr

This comment has been minimized.

Show comment
Hide comment
@intgr

intgr Dec 2, 2015

I found that the "Extended Error Information" gives some additional detail...

Missing Name Constraint for <DNS Name=helloworld.letsencrypt.org>
Missing Name Constraint for <Directory Address:CN=helloworld.letsencrypt.org>

It seems that it's getting confused by the .mil name constraint exclusion. The Name Constraints field shows:

Permitted=None
Excluded
     [1]Subtrees (0..Max):
          DNS Name=.mil

Notice how it thinks Permitted=None. Could this be fixed by adding an explicit permitted name constraint for all top-level domains?

RFC 5280 about x.509 Name Constraints: https://tools.ietf.org/html/rfc5280#section-4.2.1.10

letsencrypt-xp3

intgr commented Dec 2, 2015

I found that the "Extended Error Information" gives some additional detail...

Missing Name Constraint for <DNS Name=helloworld.letsencrypt.org>
Missing Name Constraint for <Directory Address:CN=helloworld.letsencrypt.org>

It seems that it's getting confused by the .mil name constraint exclusion. The Name Constraints field shows:

Permitted=None
Excluded
     [1]Subtrees (0..Max):
          DNS Name=.mil

Notice how it thinks Permitted=None. Could this be fixed by adding an explicit permitted name constraint for all top-level domains?

RFC 5280 about x.509 Name Constraints: https://tools.ietf.org/html/rfc5280#section-4.2.1.10

letsencrypt-xp3

@jsha

This comment has been minimized.

Show comment
Hide comment
@jsha

jsha Dec 3, 2015

Contributor

I've confirmed this using the Windows XP VM from https://dev.windows.com/en-us/microsoft-edge/tools/vms/linux/. I'll update our FAQ, and we can look at how to fix the issue longer-term.

Contributor

jsha commented Dec 3, 2015

I've confirmed this using the Windows XP VM from https://dev.windows.com/en-us/microsoft-edge/tools/vms/linux/. I'll update our FAQ, and we can look at how to fix the issue longer-term.

@intgr

This comment has been minimized.

Show comment
Hide comment
@intgr

intgr Dec 3, 2015

@jsha Thanks. Should I create a new issue to fix WinXP compatibility, or rename/edit this one?

intgr commented Dec 3, 2015

@jsha Thanks. Should I create a new issue to fix WinXP compatibility, or rename/edit this one?

@intgr intgr changed the title from Is Chrome/IE8 with Windows XP officially broken with Let's Encrypt? to Let's Encrypt intermediate not accepted by Chrome and IE8 on Windows XP Dec 3, 2015

@jsha

This comment has been minimized.

Show comment
Hide comment
@jsha

jsha Dec 3, 2015

Contributor

Any fix is going to be an administrative/signing issue for Let's Encrypt, not something specific to either the client or the server. So I'm closing out this issue. The problem is documented on the community forums now, and we'll track any possible fixes internally. Thanks so much for digging into it!

Contributor

jsha commented Dec 3, 2015

Any fix is going to be an administrative/signing issue for Let's Encrypt, not something specific to either the client or the server. So I'm closing out this issue. The problem is documented on the community forums now, and we'll track any possible fixes internally. Thanks so much for digging into it!

@jsha jsha closed this Dec 3, 2015

@centminmod

This comment has been minimized.

Show comment
Hide comment
@centminmod

centminmod Dec 3, 2015

thanks @jsha for the clarification.. maybe this can make it into official manual too at https://letsencrypt.readthedocs.org/en/latest/intro.html ?

centminmod commented Dec 3, 2015

thanks @jsha for the clarification.. maybe this can make it into official manual too at https://letsencrypt.readthedocs.org/en/latest/intro.html ?

@intgr

This comment has been minimized.

Show comment
Hide comment
@intgr

intgr Dec 4, 2015

@jsha

The problem is documented on the community forums now, and we'll track any possible fixes internally.

That's not saying much. Will you be working to create a new intermediate certificate to enable Windows XP compatibility, or is this just a polite "wontfix"?

intgr commented Dec 4, 2015

@jsha

The problem is documented on the community forums now, and we'll track any possible fixes internally.

That's not saying much. Will you be working to create a new intermediate certificate to enable Windows XP compatibility, or is this just a polite "wontfix"?

@jsha

This comment has been minimized.

Show comment
Hide comment
@jsha

jsha Dec 4, 2015

Contributor

@intgr: Sorry I can't commit more! This is a polite "very busy with post-launch at the moment, need get together a quorum of colleagues to discuss the issue in detail." :-)

Contributor

jsha commented Dec 4, 2015

@intgr: Sorry I can't commit more! This is a polite "very busy with post-launch at the moment, need get together a quorum of colleagues to discuss the issue in detail." :-)

@Depicus

This comment has been minimized.

Show comment
Hide comment
@Depicus

Depicus Dec 4, 2015

For anybody with this issue it is possible to work round with Apache and mod_rewrite using the following code

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_USER_AGENT} !(Windows\ NT\ 5.1|Windows\ NT\ 5.2) [NC]
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}

Basically pop this in your :80 .conf and Windows XP users will not be redirected to https but everything else will. You can add other user agents as required.

Depicus commented Dec 4, 2015

For anybody with this issue it is possible to work round with Apache and mod_rewrite using the following code

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_USER_AGENT} !(Windows\ NT\ 5.1|Windows\ NT\ 5.2) [NC]
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}

Basically pop this in your :80 .conf and Windows XP users will not be redirected to https but everything else will. You can add other user agents as required.

@naox

This comment has been minimized.

Show comment
Hide comment
@naox

naox Dec 6, 2015

+1
Don't give up on supporting windows xp yet please.

naox commented Dec 6, 2015

+1
Don't give up on supporting windows xp yet please.

@soukicz

This comment has been minimized.

Show comment
Hide comment
@soukicz

soukicz Dec 7, 2015

(Probably) the same problem is with Android 2.3. Certificate is loaded correctly (no SNI or protocol problem) but is refused because of "domain mismatch".

Forum topic: https://community.letsencrypt.org/t/san-domain-name-mismatch-android-2-windows-xp/4060

soukicz commented Dec 7, 2015

(Probably) the same problem is with Android 2.3. Certificate is loaded correctly (no SNI or protocol problem) but is refused because of "domain mismatch".

Forum topic: https://community.letsencrypt.org/t/san-domain-name-mismatch-android-2-windows-xp/4060

@naox

This comment has been minimized.

Show comment
Hide comment
@naox

naox Dec 7, 2015

I suspect that problem is not in intermediate certificate but actualy in the issued end certificate - in a X509v3 Certificate Policies field that windows xp certification managment tool see as hex gibberish (and in case of all other certificates on the internet it is not so). Owner of the project: please test by issuing end certificate without X509v3 Certificate Policies field or set it to something simpler or at least move it higher in the structure so its not directly below X509v3 Subject Alternative Name as its seem to interfere with it

            X509v3 Subject Alternative Name:
                DNS:xxxxxxxxxxxxxxxx
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org
                  User Notice:
                    Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/

crap

naox commented Dec 7, 2015

I suspect that problem is not in intermediate certificate but actualy in the issued end certificate - in a X509v3 Certificate Policies field that windows xp certification managment tool see as hex gibberish (and in case of all other certificates on the internet it is not so). Owner of the project: please test by issuing end certificate without X509v3 Certificate Policies field or set it to something simpler or at least move it higher in the structure so its not directly below X509v3 Subject Alternative Name as its seem to interfere with it

            X509v3 Subject Alternative Name:
                DNS:xxxxxxxxxxxxxxxx
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org
                  User Notice:
                    Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/

crap

@naox

This comment has been minimized.

Show comment
Hide comment
@naox

naox Dec 9, 2015

@soukiii

(Probably) the same problem is with Android 2.3. Certificate is loaded correctly (no SNI or protocol problem) but is refused because of "domain mismatch".

There are no problems with certificate on android 2.3.6 stock browser as I tested.

naox commented Dec 9, 2015

@soukiii

(Probably) the same problem is with Android 2.3. Certificate is loaded correctly (no SNI or protocol problem) but is refused because of "domain mismatch".

There are no problems with certificate on android 2.3.6 stock browser as I tested.

@mustenero

This comment has been minimized.

Show comment
Hide comment
@mustenero

mustenero Dec 10, 2015

Opera has the same problem as Chrome.

mustenero commented Dec 10, 2015

Opera has the same problem as Chrome.

@knyttl

This comment has been minimized.

Show comment
Hide comment
@knyttl

knyttl Dec 16, 2015

I think it would be very helpful if the generated apache configs would take these into account and WXP wouldn't redirect to https.

<VirtualHost *:80>
    DocumentRoot /www/domain.com
    ServerName domain.com
    ServerAlias www.domain.com
    RewriteEngine on

    RewriteCond %{HTTPS} off
    RewriteCond %{HTTP_USER_AGENT} !(Windows\ NT\ 5) [NC]
    RewriteRule ^ https://www.domain.com%{REQUEST_URI}
</VirtualHost>
<VirtualHost *:443>
    DocumentRoot /www/domain.com
    ServerName domain.com
    ServerAlias www.domain.com
    RewriteEngine on

    RewriteCond %{HTTPS} on
    RewriteCond %{HTTP_USER_AGENT} (Windows\ NT\ 5) [NC]
    RewriteRule ^ http://www.domain.com%{REQUEST_URI} [L]

    SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

knyttl commented Dec 16, 2015

I think it would be very helpful if the generated apache configs would take these into account and WXP wouldn't redirect to https.

<VirtualHost *:80>
    DocumentRoot /www/domain.com
    ServerName domain.com
    ServerAlias www.domain.com
    RewriteEngine on

    RewriteCond %{HTTPS} off
    RewriteCond %{HTTP_USER_AGENT} !(Windows\ NT\ 5) [NC]
    RewriteRule ^ https://www.domain.com%{REQUEST_URI}
</VirtualHost>
<VirtualHost *:443>
    DocumentRoot /www/domain.com
    ServerName domain.com
    ServerAlias www.domain.com
    RewriteEngine on

    RewriteCond %{HTTPS} on
    RewriteCond %{HTTP_USER_AGENT} (Windows\ NT\ 5) [NC]
    RewriteRule ^ http://www.domain.com%{REQUEST_URI} [L]

    SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
@mustenero

This comment has been minimized.

Show comment
Hide comment
@mustenero

mustenero Dec 16, 2015

knyttl this configuration is for apache. Have you some idea how do that on haproxy?

mustenero commented Dec 16, 2015

knyttl this configuration is for apache. Have you some idea how do that on haproxy?

@knyttl

This comment has been minimized.

Show comment
Hide comment
@knyttl

knyttl Dec 16, 2015

In the end it doesn't help as the :443 won't redirect on invalid certificate. Anyone who bumps into https:// will get the error. Now it seems to me that these certificates are completely useless.

knyttl commented Dec 16, 2015

In the end it doesn't help as the :443 won't redirect on invalid certificate. Anyone who bumps into https:// will get the error. Now it seems to me that these certificates are completely useless.

@soukicz

This comment has been minimized.

Show comment
Hide comment
@soukicz

soukicz Dec 16, 2015

It cannot be solved with redirects. It doesn't work for links to https (from Google for example) and it is huge security risk.

soukicz commented Dec 16, 2015

It cannot be solved with redirects. It doesn't work for links to https (from Google for example) and it is huge security risk.

@knyttl

This comment has been minimized.

Show comment
Hide comment
@knyttl

knyttl Dec 16, 2015

@soukiii: Yes you are right, my mistage. This means there is no way to overcome this issue for WXP users. I can't imagine any website which could settle down for only non-wxp users.

knyttl commented Dec 16, 2015

@soukiii: Yes you are right, my mistage. This means there is no way to overcome this issue for WXP users. I can't imagine any website which could settle down for only non-wxp users.

@Depicus

This comment has been minimized.

Show comment
Hide comment
@Depicus

Depicus Dec 16, 2015

@knyttl Well if you want to be PCIDSS compliant you can no longer use TLSv1 which affects a lot more that XP users, it goes to IE10 on Windows 7. So while this bug is annoying lots of sites will have to exclude IE and Chrome on XP and a whole lot more if they want to take credit card details.

Depicus commented Dec 16, 2015

@knyttl Well if you want to be PCIDSS compliant you can no longer use TLSv1 which affects a lot more that XP users, it goes to IE10 on Windows 7. So while this bug is annoying lots of sites will have to exclude IE and Chrome on XP and a whole lot more if they want to take credit card details.

@pde

This comment has been minimized.

Show comment
Hide comment
@pde

pde Dec 18, 2015

Member

For the folks who want a way to redirect some but not all of their visitors to HTTPS, there's a new ticket about that client functionality: #1942

Member

pde commented Dec 18, 2015

For the folks who want a way to redirect some but not all of their visitors to HTTPS, there's a new ticket about that client functionality: #1942

@dakusan

This comment has been minimized.

Show comment
Hide comment
@dakusan

dakusan Dec 31, 2015

Since this ticket is closed, is there anywhere that we can subscribe to follow when WinXP becomes compatible?

dakusan commented Dec 31, 2015

Since this ticket is closed, is there anywhere that we can subscribe to follow when WinXP becomes compatible?

@brianjking

This comment has been minimized.

Show comment
Hide comment
@dasa123

This comment has been minimized.

Show comment
Hide comment
@dasa123

dasa123 Mar 25, 2016

With the following Javascript code, the browser tries to load a file over https. If that works, the user gets redirected to https (source: http://stackoverflow.com/a/27896066). This might be useful if you only want to redirect browsers that support your cipher suites. In contrast to above approach (#1660 (comment)), this code also redirects visitors that use Firefox in Windows XP.

<form style="display:none;" method="get" name="redirect"></form>
<script type="text/javascript">
if (window.location.protocol != "https:") {
        var img=document.createElement('img');
        img.src='https://' + window.location.hostname + '/favicon.png';
        img.onload = function() {
                var redirect_form = document.forms["redirect"];
                redirect_form.action = "https:" + window.location.href.substring(window.location.protocol.length);
                redirect_form.submit();
        }
        img.style.display='none';
        document.body.appendChild(img);
}
</script>

dasa123 commented Mar 25, 2016

With the following Javascript code, the browser tries to load a file over https. If that works, the user gets redirected to https (source: http://stackoverflow.com/a/27896066). This might be useful if you only want to redirect browsers that support your cipher suites. In contrast to above approach (#1660 (comment)), this code also redirects visitors that use Firefox in Windows XP.

<form style="display:none;" method="get" name="redirect"></form>
<script type="text/javascript">
if (window.location.protocol != "https:") {
        var img=document.createElement('img');
        img.src='https://' + window.location.hostname + '/favicon.png';
        img.onload = function() {
                var redirect_form = document.forms["redirect"];
                redirect_form.action = "https:" + window.location.href.substring(window.location.protocol.length);
                redirect_form.submit();
        }
        img.style.display='none';
        document.body.appendChild(img);
}
</script>
@soukicz

This comment has been minimized.

Show comment
Hide comment
@soukicz

soukicz Mar 25, 2016

@dasa123 That's just wrong.

soukicz commented Mar 25, 2016

@dasa123 That's just wrong.

@dasa123

This comment has been minimized.

Show comment
Hide comment
@dasa123

dasa123 Mar 25, 2016

@soukiii I know it's not an ellegant solution. I myself just use the following on my webserver:

server {
        listen 80;
        return 301 https://example.org$request_uri;
}

But, the approach might be a viable option if you don't want to think about which browsers support SNI.

dasa123 commented Mar 25, 2016

@soukiii I know it's not an ellegant solution. I myself just use the following on my webserver:

server {
        listen 80;
        return 301 https://example.org$request_uri;
}

But, the approach might be a viable option if you don't want to think about which browsers support SNI.

@soukicz

This comment has been minimized.

Show comment
Hide comment
@soukicz

soukicz Mar 25, 2016

No, it's not. Visitor clicks on HTTPS link in Google and gets error page - javascript doesn't even load. Https would be totally pointless if it could be disabled by untrusted certificate.

soukicz commented Mar 25, 2016

No, it's not. Visitor clicks on HTTPS link in Google and gets error page - javascript doesn't even load. Https would be totally pointless if it could be disabled by untrusted certificate.

@dasa123

This comment has been minimized.

Show comment
Hide comment
@dasa123

dasa123 Mar 25, 2016

@soukiii

Visitor clicks on HTTPS link in Google and gets error page

Not everybody wants to take the risk of a big bang deployment of https-only website access and thus might set their Google Webmaster Tools and robots.txt up accordingly in order to get http links listed in the search engine results. You can't assume that every webmaster wants their website linked via https.

javascript doesn't even load

The code/redirect isn't supposed to run over https anyway:

Https would be totally pointless if it could be disabled by untrusted certificate.

And https-only access protects you?! To prevent this: HSTS, HPKP, DANE, DNSSEC/TLSA Validator, certificate transparency

dasa123 commented Mar 25, 2016

@soukiii

Visitor clicks on HTTPS link in Google and gets error page

Not everybody wants to take the risk of a big bang deployment of https-only website access and thus might set their Google Webmaster Tools and robots.txt up accordingly in order to get http links listed in the search engine results. You can't assume that every webmaster wants their website linked via https.

javascript doesn't even load

The code/redirect isn't supposed to run over https anyway:

Https would be totally pointless if it could be disabled by untrusted certificate.

And https-only access protects you?! To prevent this: HSTS, HPKP, DANE, DNSSEC/TLSA Validator, certificate transparency

@yonjah

This comment has been minimized.

Show comment
Hide comment
@yonjah

yonjah Mar 26, 2016

Contributor

The thing is @dasa123 , if you can afford to initiate insecure connection if ssl fails why can't you just do it for everyone else and drop ssl support completely?

And if the data going on the line is half critical, how can you afford to compromise users just to have more traffic ?

I think security best practice learned us that if you can't serve on a secure connection you should fail the connection with as much bells and whistles. It is in the user best interest not to interact with your site if the connection is not secure.

And you are right that https-only is only making one link in the security chain stronger, but I don't see how this is a case for making it weaker.

Contributor

yonjah commented Mar 26, 2016

The thing is @dasa123 , if you can afford to initiate insecure connection if ssl fails why can't you just do it for everyone else and drop ssl support completely?

And if the data going on the line is half critical, how can you afford to compromise users just to have more traffic ?

I think security best practice learned us that if you can't serve on a secure connection you should fail the connection with as much bells and whistles. It is in the user best interest not to interact with your site if the connection is not secure.

And you are right that https-only is only making one link in the security chain stronger, but I don't see how this is a case for making it weaker.

@dasa123

This comment has been minimized.

Show comment
Hide comment
@dasa123

dasa123 Mar 26, 2016

@yonjah Like I said, big bang deployment is not a solution for everybody. https deployment is always a tightrope walk between security and usability. If Google would follow your argumentation, they would drop RC4 based ssl ciphers. But, they want to support legacy systems and still support insecure ciphers (https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com&hideResults=on). You as a security focused person are often not the sole policy maker. This is especially true if you are responsible for a company website where the company managers, important customers etc. have a say, too.

The thing is @dasa123 , if you can afford to initiate insecure connection if ssl fails why can't you just do it for everyone else and drop ssl support completely?

You can grant website visitors different levels of usage rights, e.g.:

  • Windows XP without https support => Leave them on http and inform them to switch their operating system or at least move to current Firefox version. Disable "login" and "register" functionality.
  • Windows XP with Firefox => Redirect to https and inform them to use https in the future via HSTS
  • Modern systems => Allow only https

If hardly any website visitor comes without https support, you make the switch to https-only access.

And if the data going on the line is half critical, how can you afford to compromise users just to have more traffic ? I think security best practice learned us that if you can't serve on a secure connection you should fail the connection with as much bells and whistles. It is in the user best interest not to interact with your site if the connection is not secure.

You might not be the sole decission maker. The company might earn their money with the website...
What do you think is the reason for amazon.com still supporting http alongside https?

And you are right that https-only is only making one link in the security chain stronger, but I don't see how this is a case for making it weaker.

https is flawed by nature. Just because you allow access only over https doesn't mean that the connection can't be "disabled by untrusted certificate" (#1660 (comment)). A recent case: https://security.googleblog.com/2015/03/maintaining-digital-certificate-security.html

dasa123 commented Mar 26, 2016

@yonjah Like I said, big bang deployment is not a solution for everybody. https deployment is always a tightrope walk between security and usability. If Google would follow your argumentation, they would drop RC4 based ssl ciphers. But, they want to support legacy systems and still support insecure ciphers (https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com&hideResults=on). You as a security focused person are often not the sole policy maker. This is especially true if you are responsible for a company website where the company managers, important customers etc. have a say, too.

The thing is @dasa123 , if you can afford to initiate insecure connection if ssl fails why can't you just do it for everyone else and drop ssl support completely?

You can grant website visitors different levels of usage rights, e.g.:

  • Windows XP without https support => Leave them on http and inform them to switch their operating system or at least move to current Firefox version. Disable "login" and "register" functionality.
  • Windows XP with Firefox => Redirect to https and inform them to use https in the future via HSTS
  • Modern systems => Allow only https

If hardly any website visitor comes without https support, you make the switch to https-only access.

And if the data going on the line is half critical, how can you afford to compromise users just to have more traffic ? I think security best practice learned us that if you can't serve on a secure connection you should fail the connection with as much bells and whistles. It is in the user best interest not to interact with your site if the connection is not secure.

You might not be the sole decission maker. The company might earn their money with the website...
What do you think is the reason for amazon.com still supporting http alongside https?

And you are right that https-only is only making one link in the security chain stronger, but I don't see how this is a case for making it weaker.

https is flawed by nature. Just because you allow access only over https doesn't mean that the connection can't be "disabled by untrusted certificate" (#1660 (comment)). A recent case: https://security.googleblog.com/2015/03/maintaining-digital-certificate-security.html

@yonjah

This comment has been minimized.

Show comment
Hide comment
@yonjah

yonjah Mar 26, 2016

Contributor

If Google would follow your argumentation, they would drop RC4 based ssl ciphers.

@dasa123 Google are in the process of dumping rc4 -
https://security.googleblog.com/2015/09/disabling-sslv3-and-rc4.html

Also there is huge different between using rc4 which will offer a bit less secure connection to small part of your users (users using evergreen browsers without rc4 support are not affected, and even if an rc4 connection is made, a real world attack is hard to implement (best I know is ~50 hours for decrypting a cookie). Compare to your suggestion where XP users by design don't have any security at all, and all a MITM has to do is to drop ssl connections and now any users will not have any secure connection at all.

You can grant website visitors different levels of usage rights, e.g.:

  • Windows XP without https support => Leave them on http and inform them to switch their operating system or at least move to current Firefox version. Disable "login" and "register" functionality.
  • Windows XP with Firefox => Redirect to https and inform them to use https in the future via HSTS
  • Modern systems => Allow only https

I think this approach is totally OK if you need to have maximum availability and don't have any other choice. But your JS code (and any other solution that was offered here ) doesn't offer this solution. Any one who wish to implement this kind of solution will have to probably write it specifically for their infrastructure and the little code you have here to detect ssl has little value to none in that context.
So this solution is a bad idea since it only offers users who don't know any better a copy paste solution which is totally insecure in its published context.

If we go back to the company that want maximum availability and security for there users, they shouldn't use Letsencrypt until an xp support is available, since there are a lot of CAs out there that support XP this is a no brainer.
Thats why its vital for Letsencrypt to support XP (and hopefully they due, I'll check the new certs after the weekend )

Contributor

yonjah commented Mar 26, 2016

If Google would follow your argumentation, they would drop RC4 based ssl ciphers.

@dasa123 Google are in the process of dumping rc4 -
https://security.googleblog.com/2015/09/disabling-sslv3-and-rc4.html

Also there is huge different between using rc4 which will offer a bit less secure connection to small part of your users (users using evergreen browsers without rc4 support are not affected, and even if an rc4 connection is made, a real world attack is hard to implement (best I know is ~50 hours for decrypting a cookie). Compare to your suggestion where XP users by design don't have any security at all, and all a MITM has to do is to drop ssl connections and now any users will not have any secure connection at all.

You can grant website visitors different levels of usage rights, e.g.:

  • Windows XP without https support => Leave them on http and inform them to switch their operating system or at least move to current Firefox version. Disable "login" and "register" functionality.
  • Windows XP with Firefox => Redirect to https and inform them to use https in the future via HSTS
  • Modern systems => Allow only https

I think this approach is totally OK if you need to have maximum availability and don't have any other choice. But your JS code (and any other solution that was offered here ) doesn't offer this solution. Any one who wish to implement this kind of solution will have to probably write it specifically for their infrastructure and the little code you have here to detect ssl has little value to none in that context.
So this solution is a bad idea since it only offers users who don't know any better a copy paste solution which is totally insecure in its published context.

If we go back to the company that want maximum availability and security for there users, they shouldn't use Letsencrypt until an xp support is available, since there are a lot of CAs out there that support XP this is a no brainer.
Thats why its vital for Letsencrypt to support XP (and hopefully they due, I'll check the new certs after the weekend )

@dasa123

This comment has been minimized.

Show comment
Hide comment
@dasa123

dasa123 Mar 26, 2016

@dasa123 Google are in the process of dumping rc4 -
https://security.googleblog.com/2015/09/disabling-sslv3-and-rc4.html

... and they don't make it via big bang deployment which was the main point of this argument. They first announce, wait, test etc.

Compare to your suggestion where XP users by design don't have any security at all, and all a MITM has to do is to drop ssl connections and now any users will not have any secure connection at all.

If there is somebody having the motivation to act as a MITM and attack your website, you will not be protected by https-only either unless in some scenarios where such technologies as HPKP, HSTS, DANE etc. come into play. I didn't deny that the redirect is problematic.

But your JS code (and any other solution that was offered here ) doesn't offer this solution.

... and that's not what I claim.

So this solution is a bad idea since it only offers users who don't know any better a copy paste solution which is totally insecure in its published context.

Anybody who just applies brainless copy and past should just use the services of professionals, pay their monthly fee and avoid implementing Let's Encrypt on their system.

there are a lot of CAs out there that support XP this is a no brainer.

Even if you use such a CA, there might be other web clients not supporting your chosen webserver https settings or people still might want to redirect if possible. I think it's unrealistic to switch from http to https-only from one day to another.

dasa123 commented Mar 26, 2016

@dasa123 Google are in the process of dumping rc4 -
https://security.googleblog.com/2015/09/disabling-sslv3-and-rc4.html

... and they don't make it via big bang deployment which was the main point of this argument. They first announce, wait, test etc.

Compare to your suggestion where XP users by design don't have any security at all, and all a MITM has to do is to drop ssl connections and now any users will not have any secure connection at all.

If there is somebody having the motivation to act as a MITM and attack your website, you will not be protected by https-only either unless in some scenarios where such technologies as HPKP, HSTS, DANE etc. come into play. I didn't deny that the redirect is problematic.

But your JS code (and any other solution that was offered here ) doesn't offer this solution.

... and that's not what I claim.

So this solution is a bad idea since it only offers users who don't know any better a copy paste solution which is totally insecure in its published context.

Anybody who just applies brainless copy and past should just use the services of professionals, pay their monthly fee and avoid implementing Let's Encrypt on their system.

there are a lot of CAs out there that support XP this is a no brainer.

Even if you use such a CA, there might be other web clients not supporting your chosen webserver https settings or people still might want to redirect if possible. I think it's unrealistic to switch from http to https-only from one day to another.

@arzeth

This comment has been minimized.

Show comment
Hide comment
@arzeth

arzeth Mar 26, 2016

They fixed the incompatibility (not completely because it currently requires a little tweak — see below): https://community.letsencrypt.org/t/upcoming-intermediate-changes/13106!

I renewed my certificate (by the way, I have one cert for multiple domains):

./letsencrypt-auto renew --force-renewal

Then I changed nginx' parameter ssl_cipher (see https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations) (the following one doesn't support IE6):

ssl_cipher 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';

Then I tested my websites with Chrome and IE8 on Windows XP SP3 (no warnings, no errors).

arzeth commented Mar 26, 2016

They fixed the incompatibility (not completely because it currently requires a little tweak — see below): https://community.letsencrypt.org/t/upcoming-intermediate-changes/13106!

I renewed my certificate (by the way, I have one cert for multiple domains):

./letsencrypt-auto renew --force-renewal

Then I changed nginx' parameter ssl_cipher (see https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations) (the following one doesn't support IE6):

ssl_cipher 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';

Then I tested my websites with Chrome and IE8 on Windows XP SP3 (no warnings, no errors).

@jsha

This comment has been minimized.

Show comment
Hide comment
@jsha

jsha Mar 26, 2016

Contributor

Thanks for the input all! I'd encourage you to use the community forum to continue the conversation about how and whether to run a web server that supports both XP and newer operating systems.

Contributor

jsha commented Mar 26, 2016

Thanks for the input all! I'd encourage you to use the community forum to continue the conversation about how and whether to run a web server that supports both XP and newer operating systems.

@rugk

This comment has been minimized.

Show comment
Hide comment
@rugk

rugk Mar 27, 2016

Contributor

You can't assume that every webmaster wants their website linked via https.

But it would be clever of them to do so as Google ranks HTTPS sites higher. 😃

Contributor

rugk commented Mar 27, 2016

You can't assume that every webmaster wants their website linked via https.

But it would be clever of them to do so as Google ranks HTTPS sites higher. 😃

@xiaobailong24

This comment has been minimized.

Show comment
Hide comment
@xiaobailong24

xiaobailong24 Nov 6, 2016

win7 Chrome 53 with "This page is insecure (broken HTTPS)."
win7 Firefox no this problem

xiaobailong24 commented Nov 6, 2016

win7 Chrome 53 with "This page is insecure (broken HTTPS)."
win7 Firefox no this problem

@Chupaka

This comment has been minimized.

Show comment
Hide comment
@Chupaka

Chupaka Nov 6, 2016

xiaobailong24, what page?

Chupaka commented Nov 6, 2016

xiaobailong24, what page?

@davidearl

This comment has been minimized.

Show comment
Hide comment
@davidearl

davidearl Nov 6, 2016

Let's Encrypt fixed the original problem. Perhaps this is more likely to be SNI, which will still produce errors in Chrome and IE, but not Firefox, on WinXP for VirtualHost's other than the first one. If it's that, it's an XP problem, not a Let's Encrypt one.

davidearl commented Nov 6, 2016

Let's Encrypt fixed the original problem. Perhaps this is more likely to be SNI, which will still produce errors in Chrome and IE, but not Firefox, on WinXP for VirtualHost's other than the first one. If it's that, it's an XP problem, not a Let's Encrypt one.

@Chupaka

This comment has been minimized.

Show comment
Hide comment
@Chupaka

Chupaka Nov 6, 2016

I hope, "win7" is not XP :)

Chupaka commented Nov 6, 2016

I hope, "win7" is not XP :)

@xiaobailong24

This comment has been minimized.

Show comment
Hide comment
@xiaobailong24

xiaobailong24 Nov 7, 2016

@Chupaka Thanks for your reply. My test page is https://www.aigoogle.club

xiaobailong24 commented Nov 7, 2016

@Chupaka Thanks for your reply. My test page is https://www.aigoogle.club

@Majkl578

This comment has been minimized.

Show comment
Hide comment
@Majkl578

Majkl578 Nov 7, 2016

@xiaobailong24 your domain does not match the certificate - it's issued only for aigoogle.club, not for www.aigoogle.club.

Majkl578 commented Nov 7, 2016

@xiaobailong24 your domain does not match the certificate - it's issued only for aigoogle.club, not for www.aigoogle.club.

@xiaobailong24

This comment has been minimized.

Show comment
Hide comment
@xiaobailong24

xiaobailong24 Nov 7, 2016

@Majkl578 Thank you a lot. That's my mistake. It's OK now!

xiaobailong24 commented Nov 7, 2016

@Majkl578 Thank you a lot. That's my mistake. It's OK now!

@Lohoris

This comment has been minimized.

Show comment
Hide comment
@Lohoris

Lohoris Dec 7, 2016

Chrome 54 on Android has the same problem, and that's not exactly an old platform…

oddly, Chrome 55 on desktop works fine instead…

Lohoris commented Dec 7, 2016

Chrome 54 on Android has the same problem, and that's not exactly an old platform…

oddly, Chrome 55 on desktop works fine instead…

@jsha

This comment has been minimized.

Show comment
Hide comment
@jsha

jsha Dec 8, 2016

Contributor

@Lohoris: Most likely you're experiencing a different problem. Chrome 54 on Android usually works fine with Let's Encrypt. Can you post at https://community.letsencrypt.org/ with the name of the site you're having a problem with, and a screenshot of the error?

Contributor

jsha commented Dec 8, 2016

@Lohoris: Most likely you're experiencing a different problem. Chrome 54 on Android usually works fine with Let's Encrypt. Can you post at https://community.letsencrypt.org/ with the name of the site you're having a problem with, and a screenshot of the error?

@Lohoris

This comment has been minimized.

Show comment
Hide comment
@Lohoris

Lohoris commented Dec 17, 2016

@baptx

This comment has been minimized.

Show comment
Hide comment
@baptx

baptx Dec 4, 2017

When testing a website created with certbot on https://www.ssllabs.com/ssltest/analyze.html, I can see a confirmation that it works for Firefox and Chrome on Windows XP but not Internet Explorer:
IE 8 / XP - No FS - No SNI - Server sent fatal alert: handshake_failure
Will full Windows XP support be added in the default configuration or will we always have to do it manually? (explained here: #1660 (comment))

baptx commented Dec 4, 2017

When testing a website created with certbot on https://www.ssllabs.com/ssltest/analyze.html, I can see a confirmation that it works for Firefox and Chrome on Windows XP but not Internet Explorer:
IE 8 / XP - No FS - No SNI - Server sent fatal alert: handshake_failure
Will full Windows XP support be added in the default configuration or will we always have to do it manually? (explained here: #1660 (comment))

@davidearl

This comment has been minimized.

Show comment
Hide comment
@davidearl

davidearl Dec 4, 2017

The LetsEncrypt certificate problem with XP was fixed a long time ago. Your problem is that SNI is not supported in IE (or Chrome, I thought) in XP for https sites, which is nothing to do with LetsEncrypt.

davidearl commented Dec 4, 2017

The LetsEncrypt certificate problem with XP was fixed a long time ago. Your problem is that SNI is not supported in IE (or Chrome, I thought) in XP for https sites, which is nothing to do with LetsEncrypt.

@baptx

This comment has been minimized.

Show comment
Hide comment
@baptx

baptx Dec 4, 2017

Thanks, so even with the manual configuration, Let's Encrypt will never work with Internet Explorer on Windows XP?

baptx commented Dec 4, 2017

Thanks, so even with the manual configuration, Let's Encrypt will never work with Internet Explorer on Windows XP?

@Chupaka

This comment has been minimized.

Show comment
Hide comment
@Chupaka

Chupaka Dec 4, 2017

It does work on Windows XP. It just won't work if there are several TLS sites on single IP address.

Chupaka commented Dec 4, 2017

It does work on Windows XP. It just won't work if there are several TLS sites on single IP address.

@jsha

This comment has been minimized.

Show comment
Hide comment
@jsha

jsha Dec 4, 2017

Contributor

@baptx Please post about your site (including the full domain name) at https://community.letsencrypt.org/ and hopefully people will be able to help you debug your issue there. Thanks!

Contributor

jsha commented Dec 4, 2017

@baptx Please post about your site (including the full domain name) at https://community.letsencrypt.org/ and hopefully people will be able to help you debug your issue there. Thanks!

@certbot certbot locked and limited conversation to collaborators Dec 4, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.