On: Go 1.5 max procs default

[Rexxar]

Strangely, on my computer, Firefox reports a security error on the site. No error in Chrome.

    An error occurred during a connection to golang.org.
    security library: DER encoded incorrectly formatted
    message. (Error code: sec_error_bad_der)

I didn't have this the last time I went on golang.org.

[rockdoe → Rexxar]

The cert includes a wildcard for *.google, which Firefox rejects because it's a wildcard on a top level domain. I can't really tell who's right here from the specs.

https://bugzilla.mozilla.org/show_bug.cgi?id=1169149

[stygiansonic → rockdoe]

Good catch! The addition is for the new .google TLD.

Looks like the Chromium source code had some "protection" against this, at least at one point in time: http://security.stackexchange.com/questions/6873/can-a-wildc...

It appears that the specification (RFC 2818?) doesn't specify what is acceptable with regards to allowed wildcard certificates - leaving the various implementations to decide what is "too risky" for themselves.

[stygiansonic → Rexxar]

The certificate for golang.org was recently (re)issued. I see a "Not Valid Before" of "Thursday, May 21, 2015 at 5:39:30 AM Eastern Daylight Time".

I wonder if there is a Firefox-unsupported certificate extension in the new certificate?

EDIT: I wonder if it's related to this Firefox issue: Secure connection failed (sec_error_bad_der) due to certs with SAN dNSName entries incorrectly containing IP addresses[0]

However, it doesn't appear the golang.org certificate has any subjectAltName DNS entries using an IP address.

0. https://bugzilla.mozilla.org/show_bug.cgi?id=1148766

[throwaway2048 → stygiansonic]

The most frustrating part about this is when you want to access router/etc machines via https and an ip address it is just no longer even possible if they dont support this particular certificate extension.

Firefox doesn't even give you a way to bypass the erorr, even the error itself gives absolutely zero indication of what the issue actually IS. It's extraordinarily obnoxious.

[rockdoe → throwaway2048]

Huh? You can't put an IP into a DNS entry but you can put them into an IP entry.

[throwaway2048 → rockdoe]

Yet it worked fine for 20 years beforehand and is how a lot of management interfaces are connected to and used. Now a minor bit of certificate paper work is wrong by fiat, anything relying on it is no longer allowed to work, peroid, even with a manual override.

Great. I guess I'll just fork out $10k to satisfy some stupid technicality.

[rockdoe → throwaway2048]

Your argument could be used against pretty much any of the tightenings up wrt. HTTPS certs that have been done for the last few years.

"We used to be able to do whatever and be marked a secure and now we actually have to do security right! UNACCEPTABLE".

Not very convincing.

[vacri → throwaway2048]

Firefox doesn't even give you a way to bypass the erorr

Removing the 's' from 'https' in FF works for me.

[throwaway2048 → vacri]

and if that dosen't exist or auto redirects to https you are screwed. No matter how you slice it not even allowing an override over something like this is super shitty.

[droopyEyelids → throwaway2048]

Not super shitty, a judgement call.

Browser defaults have to be created to cater to the greatest (lowest?) common denominator. And if you can't figure out how to bypass the SSL warning you shouldn't bypass it.

[throwaway2048 → droopyEyelids]

there is no way to do so without patching firefox, that is way extreme. Especially for something that amounts to "you put a number in the wrong field of your cert, because this standard didn't even exist yet"

This does not improve security in any meaningful way whatsoever.

[nickysielicki → Rexxar]

Same issue here, using firefox.

openSSL doesn't complain though:

    sielicki@wetdog ~ $ openssl s_client -connect golang.org:443 -CApath /etc/ssl/certs
    CONNECTED(00000003)
    depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
    verify return:1
    depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
    verify return:1
    depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
    verify return:1
    depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.appspot.com
    verify return:1
    ---
    Certificate chain
     0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot.com
       i:/C=US/O=Google Inc/CN=Google Internet Authority G2
     1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
       i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
     2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
       i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
    ---
    <...>
    Start Time: 1432839068
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
    ---

Makes sense, I guess... firefox/iceweasel don't look at /etc/ssl/certs, they only trust what mozilla puts out.

[lukevers → Rexxar]

Same here. If you go to the link without ssl it'll load for you though.

[httpseverywhere → lukevers]

HTTPS Everywhere is the bane of my crap-configured-ssl-server existence :(.

[tyho → httpseverywhere]

Click on the icon in the menu bar. It allows you to disable the rules for domains where it is broken.