I'd appreciate your help in testing HTTPS/SSL here on PowerShell.org. Right now, it's "voluntary," meaning you have to explicitly ask for https://powershell.org. If you have any problems, please note them in a comment on this article.
Some notes and known problems:
- Most pages will not show the "lock" address bar icon in your browser, because we're delivering mixed content. For example, the site logo is being hardcoded as http:// by some Javascript in our theme, which I need to sort out.
- Your connection will be to CloudFlare, which is who issued the certificate you'll see. We've also SSL'd the traffic between them and our server using a DigiCert SSL certificate. We're also going to enable client certificate authentication, so our server will only deliver content to CloudFlare, which then delivers it to you. That's ahead.
I think we can solve the mixed-content problem by forcing HTTPS, which is easy, but I want to make sure it's otherwise working before taking that step. We already have a WordPress plugin in place that's rewriting http:// or https:// with just // in URLs, but there're a couple of places where that plugin isn't able to help, and that's why we're delivering mixed content still.
I'll point out that this is mainly a bonus-points project; because almost everyone logs into the site using an external account, we don't store many passwords (and thus don't transmit them in the clear or otherwise). We don't store or transmit any other personally identifiable information. Still, SSL has some other benefits, and it shouldn't hurt to have it on, so we're giving it a shot.
Thanks!
UPDATES 15 June 2016
- The Lock icon in browser address bars should be working; we've fixed the mixed-content issues I've found.
- We're forcing HTTPS.
- We use CloudFlare; you're getting SSL from you to them, and they're getting (forced) SSL from them to us.
- We're getting an "A" from SSLLabs and SecurityHeaders.io - thanks for that suggestion, Paal. CloudFlare doesn't let us implement every security header yet, but we've got most of the recommended ones.
If you come to site as HTTPS without being logged on first then logging into WordPress site will redirect you back non-HTTPS enabled link
Are you logging in using a username/password, or one of the social account connections?
Social Account
Should be resolved.
I was automatically using HTTPS when visiting the site, getting the green padlock in Chrome.
I can’t seem to login at the moment, however, using a social account. It goes through the process (all over HTTPS from what I can see) then redirects me to the homepage but still logged out.
Interestingly I am now logged in after posting a comment (I had refreshed and navigated around before writing a comment.) Go figure.
That was your browser caching the non-logged-in page. We have fairly aggressive caching for visitors.
Yup, I am seeing similar behavior.
I’d suggest dumping your browser cache (not not cookies, since that’s what keeps you logged in) to force it to reload the page. This isn’t new, by the way, and has nothing to do with us moving to SSL, apart from the SSL move forcing you to log in again.
I tried that, was still intermittent. It seemed to resolve itself after a day so though, so it’s all good.
Now that I am logged in, it appears that I’m being authenticated by IP address? I made some changes to my profile and wanted to see what they look like when not logged in so fired up another browser (that I’m not even signed into the social account on), navigated directly to my profile and was greeted as a logged in user.
Tried a third browser, my phone, and even a freshly imaged desktop that I’ve never touched before. All showed up as logged in with the ability to make edits. Given we have one or two public facing IP addresses for a few hundred users… this could be an issue.
We don’t authenticate by IP address, no. It’s more likely you’re using a browser which is sharing cookies amongst instances of itself. Authentication on the site is cookie-based. I can’t imagine how stupid it would be to try and authenticate by IP address; certainly, WordPress has never done that. And if your test was done with an entirely different brand of browser, then it’s entirely possible something else on your network is doing some caching or cookie-handing-over on your behalf, without you realizing it. Believe me, people got some funky stuff going on on their networks. I see a lot of odd behavior traceable to proxies and firewalls.
I’m glad to see that the page is starting to use HTTPS 🙂
As I saw replied on twitter ( https://twitter.com/PSHOrg/status/742357687900463104 ) you should probably check out the SSL report on ssllabs:
https://www.ssllabs.com/ssltest/analyze.html?d=powershell.org
What you also could do is consider some of the headers mentioned on this page:
https://securityheaders.io/?q=https%3A%2F%2Fpowershell.org
Thanks, appreciate it!
Again, thanks – we’re getting an “A” from both sites.
I can no longer connect from behind my corporate proxy. This could be our setup but reporting for info.
Error 1409443E:ssl routines:ssl3_read_bytes:tlsv1 alert inappropriate fallback
The SSL handshake could not be performed.
Don’t know if it has anything to do with anything, but you have a seemingly broken link on the “Swag” page.
The RedBubble image isn’t showing up for me that’s pointing to this url: https://stage.powershell.org/wp-content/uploads/2016/05/redbubble-logo-1.png, and the link to the RedBubble is giving me an error in chrome saying it’s passing invalid credentials when I click this url: https://powershell.org/swag/www.redbubble.com/people/devopscollectiv