SSL is coming - prepare...

[dh1]

well, Chrome on Windows likes to opine:

"Obsolete Connection SettingsThe connection to this site uses a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA with P-256), and an obsolete cipher (AES_128_CBC with HMAC-SHA1)."

from what I've read, Google/Chrome would prefer that the HMAC be "better than" SHA-1.

this makes Google/Chrome happy:
"The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA with P-256), and a strong cipher (AES_128_GCM)."

[Madpoo]

Originally Posted by marigonzes

I am glad to see the move to https. Great job!

I just have one thing to point out. When I access the website over https, my browser says that the website uses an obsolete cipher (AES_128_CBC with HMAC-SHA1). Don't know if this is a problem or not, but I guess it would be nice to take a look.

https://www.ssllabs.com/ssltest/anal...nne.org&latest

"A" rating, I'm happy with it.

Bear in mind, the cipher suites the server supports have to be able to cover some older browsers. I don't know if disabling that particular one would create problems for other browsers, but it's a strong enough set that I'm not losing sleep (and of course, the site didn't have security at all, and it's not being forced to SSL yet anyway) LOL

[Mark Rose]

Originally Posted by Madpoo

https://www.ssllabs.com/ssltest/anal...nne.org&latest

"A" rating, I'm happy with it.

Bear in mind, the cipher suites the server supports have to be able to cover some older browsers. I don't know if disabling that particular one would create problems for other browsers, but it's a strong enough set that I'm not losing sleep (and of course, the site didn't have security at all, and it's not being forced to SSL yet anyway) LOL

It probably has to do with the server's preferred list being out of ideal order.

[Madpoo]

Originally Posted by Mark Rose

It probably has to do with the server's preferred list being out of ideal order.

Yeah... that occurred to me too. I may switch it around so the higher bits are preferred. If I do that, Windows needs a reboot for schannel to pick up the new order so I may just change it and then let it fix itself the next time I do maintenance and need to reboot anyway. Not really worth a reboot just for that.

EDIT: Ah... I remember what I did! When I was setting up the cipher list, I deliberately ordered the 128-bit AES ciphers first because I wasn't sure how it would impact server performance when it started encrypting everything. I thought it'd be better to see it at that level before going to 256-bit. So I did change the recommended order when setting that up, on purpose. LOL Funny I forgot about it until I just looked at the list again.

Here's the current order of preference:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

[Mark Rose]

It shouldn't make a huge difference.

It's got a Xeon E5420 CPU, correct? It's a shame it doesn't have AES-NI.

[Madpoo]

Originally Posted by Mark Rose

It shouldn't make a huge difference.

It's got a Xeon E5420 CPU, correct? It's a shame it doesn't have AES-NI.

Dual X5550's. I wouldn't be too concerned if it was just a web server but it's more about making sure the SQL side of things isn't disrupted if the web side starts eating more cycles.

I think it'll be just fine so I just need to add the rule to redirect to https and see what happens. I'd prefer to do that maybe over next weekend when I'll have a 3-day weekend to monitor performance and adjust if needed... I may plan for that.

[Madpoo]

I noticed this behavior in Chrome 56 already, but I just got the official notice from Google that they're keeping an eye on our humble little site:

To: owner of http://mersenne.org/

Beginning in January 2017, Chrome (version 56 and later) will mark pages that collect passwords or credit card details as “Not Secure” unless the pages are served over HTTPS.

For a year, maybe two, the rumor mill was that Google gives a boost in search results (of some amount or another) to secure sites. I can imagine them getting more aggressive with that over time.

Mersenne.org isn't a huge recipient of links from the search engines, but it does get a good amount, and it's good to see it rank high when people search for prime number related things.

Anyway, all the more reason for SSL.

You may have noticed that in addition to the milestone page, I also redirect to SSL for the "shortcut" exponent reports like www.mersenne.org/M43076291

You'll get sent off to https land for those too.

[Madpoo]

Okay... rule in place now to redirect everything to HTTPS.

With our 3-day weekend (in the US, for Presidents Day) I figured this was a good chance to do it since I'll have time to check for any performance impact or respond to anyone who had some hitherto unknown dependency on non-secure connections.

The old v4 clients that still connect should be unaffected... they connect to "mersenne.org/cgi-bin/whatever" and don't play well with *any* kind of redirection to www and I'm 100% certain they wouldn't work with https at all. I'm amazed there are v4 clients still running, but it's a big, beautiful, wonderful, and utterly bizarre world.

[Madpoo]

Originally Posted by Madpoo

Okay... rule in place now to redirect everything to HTTPS.

It's surprisingly squirrely, by the way. The IIS rewrite module does weird things... First off, I have two rules, one to redirect "mersenne.org" to "www.mersenne.org" except if it's from the v4 clients which connect to "mersenne.org/cgi-bin/pnHttp.exe" (yes, a lovely old thing... it's not really cgi exe anymore though, just a PHP in disguise).

Then another rule to take http -> https.

Those were working great, *except* if it was to the root directory. For whatever reason, (.+) does NOT match a path of nothing (although in truth the path is "/".

I ended up changing things around on both rules to do a negative match of cgi-bin/(.+) instead which achieves the same goal and makes that home page redirect as needed.

IIS is weird, in other words. Anyway... I've tested things and it *should* be fine but I wanted to mention it in case anyone saw something being weird. I mean, for goodness sake, other pages were redirecting okay in my testing, but if I went to http://www.mersenne.org/accounts it was redirecting me to the secure home page for some reason. Works now, but like I said... squirrely. Simply doesn't behave in a logical way.

Oh, plus, it's late...might not be at 100%. LOL

[chalsall]

Originally Posted by Madpoo

Oh, plus, it's late...might not be at 100%. LOL

Hey Aaron... Something strange is going on...

When you first announced the SSL transition, I configured the GPU72 proxy to change all http requests to https. Worked like a charm.

This morning I noticed that the proxy is seeing "404 Not Found" responses from Primenet. When I cut and paste the https URLs from the logs into a browser, it reports:

v5.mersenne.org uses an invalid security certificate. The certificate is only valid for the following names: www.mersenne.org, mersenne.org Error code: SSL_ERROR_BAD_CERT_DOMAIN

If I bypass the warning, it returns 404.

Edit: Forgot to mention... The URLs the proxy sees are of the form "https://v5.mersenne.org/v5server/?v=0.95&px=GIMPS ...". Removing the "http -> https" regex fixes the issue.

[Madpoo]

Originally Posted by chalsall

Hey Aaron... Something strange is going on...

When you first announced the SSL transition, I configured the GPU72 proxy to change all http requests to https. Worked like a charm.

This morning I noticed that the proxy is seeing "404 Not Found" responses from Primenet. When I cut and paste the https URLs from the logs into a browser, it reports:

If I bypass the warning, it returns 404.

Edit: Forgot to mention... The URLs the proxy sees are of the form "https://v5.mersenne.org/v5server/?v=0.95&px=GIMPS ...". Removing the "http -> https" regex fixes the issue.

Oh... yeah, the API address "v5.mersenne.org" is separate and doesn't have it's own certificate. It's on the same IP address though (host headers) so any HTTPS would have gone to the main website instead of the API.

I'm not sure how that would have worked before though. The only change I made was redirecting http -> https on the website.

Anyway, if you flip the API back to http it'd be fine. I guess at some point I could add a certificate to the API as well, but there's really not as much point in that.

EDIT: I guess I should ask... what URL does the GPU72 proxy hit? If it's hitting something on the main site which is then configured to forward you to the API, it might be keeping it https when really that transition should be back to http for the API hit. I'll dig a bit on my side to try and figure this out as best I can too.