Is there any excuse for NOT having a HTTPS connection nowadays?

My university has so many unprotected subdomains that we're supposed to use and LOGIN ON that are not protected. Although these login forms are https protected the rest is not and seems sketchy.

The only excuse is neverssl.com

Recommended for all the "but my site doesn't need https" people:

https://doesmysiteneedhttps.com/

@Fast-Nop Ironically the certificate of the Dutch version of that website has expired

But thanks for mentioning it!

@alexbrooklyn what Dutch version?

@Fast-Nop https://heeftmijnwebsitehttpsnodig.nl/... auto-redirect

@alexbrooklyn oh, their LE cert expired 2 weeks ago. Looks like they botched up their auto renewal. But the redirect seems to be selective, probably geo-IP. I don't get redirected.

@Fast-Nop I emailed the person at the bottom of the page about it, hopefully it will be fixed soon :D

>Because cert maintenance is hard and we don’t want to deal with it.

You asked for an excuse, here is one I’ve heard.

@bkwilliams I just wanted to say that it isn't hard because LE has automatic renewal, but I guess that argument went out of the window. ;-)

However, good hosting providers just slap an LE certificate on a domain automatically even on shared hosting, and for free, so that's no work at all.

@Fast-Nop my org self hosts, uses software to generate certs (how it’s not self signed, I’m not sure), then the CMDB opens a Service Request when the cert nears expiration (if the date was entered into the CMDB correctly), then the cert is manually setup on the box. We have cert failures almost weekly because someone failed at that step. Yes I’ve told them about https://github.com/Netflix/lemur but it’s not my team so I can’t drive it further.

@bkwilliams yeah, having a workflow with a lot of manual steps instead of automating makes it likely that someone screws up. It's not an argument against https, but against manual workflows.

@Nanos see the second comment in this thread. There is a link that you can click and read.

@Fast-Nop True, but in many cases people equate a workflow with the tech itself. Like the meme of the kid who sticks a stick into his own bicycle wheel and blames something else.

No, there are no valid reasons for that. Even if you provide plain read-only html to users, mitm could replace your inner hrefs with smth malicious. A tiny bit of phishing effort et voila - your users are pwned. Its bad for business. Its bad for your image. And it's plain and simple irresponsible

@netikras that MITM does happen in South-East Asia and the US with provider injected ads. Not the hosting provider, but the end user provider.

Google made https a ranking signal in search, somewhat abusing their monopoly, but this time actually for the public good.

@Nanos wrong.

@Nanos is my English THAT bad?

Not all NEED a cert (if there’s no form data then sure why not), but for the lack of effort needed these days to add a cert, why not spend 5-10 minutes adding one. Some hosts even generate LE certs for you and auto renew them.

@Nanos Got cha. Well I am no official guide nor can I give any refs, but from my point of view anything facing public internet (or in fact - anything facing environment you cannot control/are likely to lose control of) should have ssl enabled. SSL does not have to be configured for your app -- it could be on WAF (at least that's what I mostly see). In that case all application's communications in inner LAN/inner infra are non-encrypted. In an event of security breach resulting in villain accessing your LAN, all application communications could be potentially leaked, so if you only terminate ssl on WAF make sure to protect your NW infra. Take into consideration that other apps in the same infra could get hacked as well, which could also result in your whole LAN being compromised.

The drawback of SSL is that it's quite costly (performance-wise). But that should never mean that you don't need it where risks are high - internet-facing/HI-risk comms.

@netikras it isn't costly because modern CPUs support quite some needed instructions. I remember Google reporting something like 1-2% increased server load.

The initial handshake costs one roundtrip more, that's nasty especially on mobile. BUT you get http/2 in return, which is only supported via https, and that makes more than up for the handshake.

@Fast-Nop the handshake is what I had in mind :) bcz it means additional nw traffic, additional tcp payloads. While a plain-text exchange means 2 data packages [lets ignore chunking]. Ssl handshake at least doubles that [do not remember the whole handshake by heart, but cert xchange, symm key exchange,...].

@netikras the traffic is irrelevant with the average website size these days, it's the latency - but that is addressed by http/2 where you need fewer TCP connections.

Why would I want https for a static site? It's just unnecessary overhead.

@toriyaki https://doesmysiteneedhttps.com

@alexbrooklyn none of those points matter for static sites.

Furthermore, some of the points are flat out misleading/wrong.

@toriyaki Spoofing of links and/or text can still happen 🤔

Weird, the Dutch version of that site does mention it

@alexbrooklyn sure. But I'm worried about that as much as I worry about someone coming into my bedroom and attacking my computer: it's such a low risk, that it's a non issue.

The overhead of https is too much right now. Dealing with renewals, properly configuring DNS, handling redirects, etc. Yes, those are "easy" steps to address, but it's extra steps nonetheless for no benefit. And those are just the most common issues.

What if you want to setup a caching proxy? You need to roll out a root certificate. Again, unnecessary IT complexity. Extra points of failure.

It makes no sense for simple static sites.