7 ms·

Serious question: if I just run a simple blog with static HTML hosted with Apache, do I really need HTTPS? Will I be penalized by not having it?

• saagarjha 9y ago
  It doesn't look like it right now: > all websites with form fields served over HTTP will show a "Not secure" warning to the user As long as you don't have a form field, you should be fine.
  • marksomnian 9y ago
    I believe the Chrome team has (or at least had) long term plans to mark all HTTP sites as actively dangerous, form fields or not. So, you'll be fine for now, but there will come a point when you will need to implement HTTPS.
• JonRB 9y ago
  My understanding is that you will already be ranked lower on search engines. My main concern with this happening is that browsers are going to get a reputation for being 'alarmist', so when something really goes wrong, they won't be able to communicate it effectively.
  • seanwasere 9y ago
    alarmist media gets the most clicks, perhaps browser developers see a new way to push products to people, bit like when your antivirus shows alerts in your screen all the time. they are essentially pushing there own products by flashing there logos in your face all the time.
• jaas 9y ago
  You won't have confidence that your visitors see the content you serve as you intend because it can be modified in transit. Your visitors will be broadcasting at least the exact address of the pages they read on your blog, and are vulnerable to anything that gets injected into your traffic in transit (e.g. malicious script). Every website should use HTTPS. It's the right thing to do. It's not hard to do these days.
  • reustle 9y ago
    > Every website should use HTTPS. It's the right thing to do. It's not hard to do these days. Unless you use simple tools like GitHub pages. I have a bunch of tiny JS heavy static projects on Pages that I can't easily add HTTPS to.
    • ehnto 9y ago
      That doesn't really change the parent comment. Just because it's harder sometimes doesn't mean it shouldn't be done. A current project of mine has some usability issues because it accepts external API requests but I won't allow non HTTPS. It would give me great pleasure to accept all possible APIs, but it's just not right to open users to that risk.
    • clfougner 9y ago
      Route your page through Cloudflare (or presumably any other CDN) and you can get HTTPS set up on your Github Pages hosted static site quite trivially.
    • clfougner 9y ago
      Route your page through Cloudflare (or presumably any other CDN) and you can get HTTPS set up on your Github Pages hosted static site quite trivially.
    • MBlume 9y ago
      I'm probably misreading you somehow -- if your site is hosted by Github isn't it already HTTPS?
      • Santosh83 9y ago
        It is, unless you want to use a custom domain with it. With the latter case your only choice to retain some semblance of HTTPS is to put it behind a CDN, but that still breaks end-to-end HTTPS. The problem really has to solved at Github's end, by allowing users to upload their own certs.
• 3pt14159 9y ago
  3% of routers in Canada and the US have some kind of malware in them, and almost all other countries are worse off. You might not need HTTPS, but I need you to have it so I can trust downloading a PDF when I'm on your site. I need it so I don't get MITM by some shitty black hat tracking company. I need it so while I travel I don't have to worry about shitty governments tracking what I'm reading or watching. And if your answer is "sure, but there will be other websites that are HTTP" my response is "yeah, but one day soon when enough of the web is secure I'm going to disallow all HTTP connections from my browser". And eventually I'll disallow all connections that aren't on HSTS preload lists. And eventually, hopefully, I'll disallow websites that don't have HPKP with long expires.
  • pjmlp 9y ago
    Then let me tell you it is quite easy to MITM by any company owning part of the connection. Many moons ago I was using a proxy engine capable of unpacking/packing HTTPS requests. It was an in-house proxy taking advantage of Apache and IIS APIs for certificate management and SSL connections. We used it for debugging secure connections, but I can easily envision other purposes. Many years have passed since 2000, but I am quite sure it is still quite possible to do it.
    • laumars 9y ago
      I won't comment on how you built your proxy but HTTPS has come a long way since, eg TLS wasn't common back then and SSL has since been deprecated. These days the only viable way to MITM HTTPS is to either attack the connection while it's in plain text HTTP (ie before the browser redirects to HTTPS:// (which is where the HSTS header comes in to play - it's cached by browsers telling them to default to HTTPS and never attempt a plain text connection) or to form your own HTTPS connection with your own CA signed certificate for the target site. Which would mean you'd either need to compromise a signing authority or have your own CA certs already installed on the victims PC (the latter is what some bad ISPs reportedly do when they inject ads). Edit: I believe some corporate network proxies also work on the principal of having their own CA certs on their business workstations - so maybe this was how your proxy worked as well?
• mholt 9y ago
  Answer: https://doesmysiteneedhttps.com https://doesmysiteneedhttps.com Yes, search engines will penalize you. ISPs will intercept traffic and change it. Your site will load slower. The problems with plain HTTP go on and on.