Pros and cons of HTTPS (split thread)

I really don’t get why nowadays with free SSL certificates developers still not use them.

This is a cultural problem among Software Developers in all programming languages that are not trained with treating security as a first class citizen in everything they do.

Despite being a static website is still vulnerable to man in the middle attacks, thus impersonating end users is a possibility here.

So this attitude must change and the example must come from upstream, from framework creators, from authors of the programming languages, from anybody that as the power to influence others.

The site is hosted via github pages AFAIK, and currently you can not use HTTPS with a custom domain there. So its due to a technical limitation.

So is time to find other place to host the site… maybe in Google Cloud free tier?

NOTE: Gitlab supports ssl in the static sites they offer https://about.gitlab.com/2016/04/11/tutorial-securing-your-gitlab-pages-with-tls-and-letsencrypt/

Oh it seems that Github now supports ssl in their github pages https://blog.github.com/2018-05-01-github-pages-custom-domains-https/

So @chrismccord does not have an excuse to not secure the site now :slight_smile:

It may be better to post this as an issue on the Phoenix site’s GH - perhaps include the link to the post in @Exadra3 's post?

Personally I don’t see https as a big deal for a static websites. Encryption also takes an extra bit of computational power and while not significant for a single site, when it’s millions of static sites what is the cost to the environment?

(This forum is hosted in a carbon neutral datacenter btw :lol:)

1 Like

I agree unless someone comes with solid evidence that static with no login protected area sites are vulnerable without SSL :sunglasses:

I think a point that’s being missed is that just because something is “secured” via SSL, doesn’t mean that the site is secure.

SSL gives you privacy, not security, webapp or not… and I’d prefer all my browsing private :slight_smile:

I think SSL on the Phoenix site would be a great idea, so +1 that the Github repo is probably the better place to have the discussion.

2 Likes

Well they are vulnerable to man in the middle attack where they can change any of the content, like links or any other bit that suites the needs of the attacker.

Plus man in the middle attacks are also performed by some ISP providers https://twitter.com/JohnMu/status/939057287796228096

1 Like

Is a big deal if you care that your readers cannot end up being fished by a man in the middle attack, like prompting them to give away some personal information as part of some campaign you are running, but that in reality is the hacker is running it in your site.

Offering the user of the site to download for example a free sample of your latest book in PDF that contains a malicious script embed and many more other scenarios…

Well if https can be faster than http , then from the client side prespective the cost for environment is positive for https :wink:

2 Likes

I keep forgetting that some ISPs may not operate to the same standards as some of us have become accustomed to… so… yes, for that reason alone perhaps it is a good idea after all :003:

5 Likes

The intense shilling to use SSL for static website is a little much. SSL for static HTML prohibits MITM, but not great from a privacy perspective. With SSL the ISP still knows exactly what pages you request, all your browsing activity is still logged. SSL actually makes the privacy situation worse because you can’t render from a local cache. A mixed bag.

Having said that, I myself just went thru the exercise, now that GitHub supports SSL for custom domains. You have to update your IP addresses with your DNS registrar (get the new addresses here https://help.github.com/articles/setting-up-an-apex-domain/), then turn off your custom domain, then turn on your custom domain again to trigger the generation of the SSL cert.

I’m pretty sure with HTTPS only the hostname (DNS request) and ip/port is exposed to the ISP since that is required for TCP/IP routing. The rest of the browsing history including full URL w/querystring in addition to the headers and the payload are all encrypted, so they can know what servers you are hitting but not what pages you are requesting. The DNS request is unfortunately insecure still but you can improve privacy a bit by using something like 1.1.1.1.

Good to know Github supports SSL for custom domains now… and I think since they are using Let’s Encrypt it’s free which is great!

1 Like

The ISP sees all your traffic and can easily log it. This paper shows that pages visited (ie URL) can be determined quite effectively. https://scirate.com/arxiv/1403.0297.

“We present a traffic analysis attack against over 6000 webpages spanning the HTTPS deployments of 10 widely used, industry-leading websites in areas such as healthcare, finance, legal services and streaming video. Our attack identifies individual pages in the same website with 89% accuracy […]”

I turned on SSL for my own static site. But to promote HTTPS as some sort of cure-all with no downsides is really ignorant.

If you get on your country’s intelligence services bad side, there is not much that you can do – that much is true.

That should not mean you must not make the lives of all other nosy organizations that much harder though. Given enough hurdles, attackers quit. Mass surveillance mostly works on the principle of gathering the lowest hanging fruits, not all possible fruits. (And as we all know, most people make it pretty damn easy to be tracked.)

I have friends who worked (and some still do) in ISPs. They say that they don’t bother logging anything except what the law mandates them to – namely which customers visited which IP when, that’s all (for 3-6 months). They all say logging customers is way too expensive for the ISP unless they are a country-wide mobile operator – and even then some don’t do it because they don’t want the extra expense.

That won’t stop a state-sponsored ISP from doing it, of course. With ongoing efforts to hide even DNS lookups however, even state-sponsored ISPs will face some really tough times Soon™.

Not so long ago, if you wanted to publish a dissident point of view, all you needed was a server and an IP address. Everybody in the world could access your information and you didn’t need to ask permission.

An SSL certificate is a license to publish, issued by a centralized organization that will necessarily bend to political pressure when it comes.

Did you ever notice that Let’s Encrypt requires you to renew your certificate every few months?

Fostering dependency on an infrastructural choke point is a power move.

Opt-In / limited SSL is fine. But I hope we reject universal encryption and the potential downsides it brings.

1 Like

I did notice, yes! Anyone know what their (official) reasoning is?

The public rationale that I’ve seen is to intentionally encourage automation of the certificate acquisition and renewal process. I don’t see any reason to consider that a nefarious goal.

3 Likes

I’d also expect that it’s a sanity measure. It’s a way more automated system than that of other SSL authorities and if something goes wrong they don’t have to deal with that for a year or even more.

4 Likes

I prefer 9.9.9.9 from https://www.quad9.net/