10 ms·
A basic guide to when and how to deploy HTTPS
- eonil 13y agoIt would be better to define HTTPS by default, and plain HTTP for exceptional cases. I would use HTTP only for strictly public and eternally cacheable big files.
- facorreia 13y agoUseful tips here.
- njharman 13y agoQ: When to deploy https? A: Always.
- tomkinstinch 13y agoInterestingly, the store side of Amazon appears to only use HTTPS for pages requiring credentials or those directly involved in a transaction. Try to view a product under HTTPS: it will redirect to HTTP. Session cookies can be intercepted and certain actions (adding an item to your wishlist, for example) can be completed without https. It seems that even with their compute resources Amazon has deemed the cost of deploying HTTPS on every page to be prohibitive.
- belluchan 13y agoAmazon is in a rare situation. They have razor thin margins and page load times can be equated to actual money lost. I doubt that can be said for very many websites. Personally I'd very much like what products I look at while shopping to be private. Some enterprising little daughter or son may be snooping the wifi during christmas shopping season trying to figure out what is being bought for them you know.
- primitivesuave 13y agoYou've taught your kids well :)
- devhinton 13y agohaha impressively well
- kyrra 13y agoSounds like you should run a VPN server somewhere you can tunnel through when Christmas shopping.
- Myrth 13y agoMany people prefer partial HTTPS only for pages that need it. The danger of hijacking session id, mentioned in the article, is mitigated by IP protection - remembering client IP when session is created, and denying access of this session id for any other IP.
- laumars 13y agoFrom an idealistic point of view you're right, but in practice I disagree as HTTPS doesn't have persistent cache. So even without the encryption overhead, HTTPS can be very costly for popular sites if they don't have user logins (eg news sites).
- tlogan 13y agoI still have to build company where I see problem where HTTP makes things faster than HTTPS. When I come to level that HTTPS is causing too much CPU usage I will be super super happy.
- joevandyk 13y agoit's not the cpu usage people worry about generally, it's the extra network trips / latency.
- riquito 13y agoSPDY requires encryption and yet it's overall faster than HTTP. If you have HTTPS on you may as well serve your pages over SPDY to the browsers that support it
- laumars 13y agoSPDY is less secure than HTTPS though[1]. Plus also supported by less web browsers / HTTP clients than HTTPS too. [1] http://www.pcworld.com/article/262307/crime_attack_abuses_ssltls_data_compression_feature_to_hijack_https_sessions.html http://www.pcworld.com/article/262307/crime_attack_abuses_ss...
- riquito 13y agoDid you even read the article you linked? The CRIME attack involves SSL/TLS, that both HTTPS and SPDY use.
- 13y ago
- why-el 13y agoWell as long as you have the money. I know it's might be trivial for some, but for instance paying 20 dollars a month for Heroku SSL when you are running an app and you are in a developing country (me for instance) is a bit much.
- ars_technician 13y agoPaying for Heroku is a little much.
- why-el 13y agoTrue, but it can sustain a free app for a long time given how small the niche is. It's only when you want to consider SSL when things get crazy..
- jiggy2011 13y agoWhat if some of your users will be behind a network level web-filter (like the one soon to be deployed in the UK)? If you run HTTPs your entire site will be blocked because 1 page fails the filter (because of a single swear word for example).
- pushrax 13y agoHTTPS means PG-13 in the UK's network filter?
- jiggy2011 13y agoWith https the filter cannot mitm and figure out which page is being accessed, so will have to block the entire site.
- BgSpnnrs 13y agoWhat filter are you discussing? AFAIK UK filtering is done by ISPs and conforms to their own solutions, there is no plan for a statewide filtering system.
- jiggy2011 13y agoThe filtering will be enabled by default for all large ISPs, so potentially a large % of the UK. You have the same problem with HTTPS either way.
- revelation 13y agoI do not think thats how these filters operate. No banking/shopping site would properly function. They are just stupid IP based filters.
- JoshTriplett 13y agoThen HTTPS is doing its job by preventing an active MITM attack by a hostile third party. Option 1: negotiate with the filter maintainers to get your site whitelisted; that may require changing your content, but a site in which you have a commercial interest probably shouldn't have content on it that trips most filters (with some obvious exceptions on which the filter would be doing its job). Option 2: inform your users that they need to opt out of the filter in question, assuming they're in a situation/regime that allows doing so. Make it clear to them exactly which content is tripping the filter, and hope their reaction is "that's absurd". Option 3: maintain an insecure HTTP site for use from such locations, and arrange to redirect there or inform your users that they'll need to use that version due to the filter they're using.
- arn 13y agoit's not quite that easy. If your adnetwork doesn't support SSL, you get mixed-content warnings. Same issue if you allow external images to be included (such as on a forum). You have to then host a caching proxy for external images.
- _delirium 13y agoFor big sites, sure. But at least as things currently stand, that's infrastructure-inconvenient and somewhat pricey on the low end, especially if you operate multiple sites and they come and go as hobby projects. Not because of the compute overhead (negligible for my uses), but because of the need for a (non-self-signed) SSL certificate, plus a unique IPv4 address, for each domain. Digital Ocean, for example, won't give you more than 1 IPv4 address per VPS, which means you need a separate VPS for every side project, if you want to go HTTPS. I prefer to multiplex all my tiny projects on one VPS, saving both the extra $60/yr per project and the extra sysadmin overhead. Plus $50/yr for the certificate, and $15 for the domain, and you have a startup cost of $125/yr per side project... versus $15/yr that it currently costs me. Not huge, but more than I want to pay, and raises the mental friction on something that I currently consider near-free/throw-away. If IPv6 actually gets deployed to the extent that I can have an IPv6-only site without needing IPv4 addresses, and someone solves the SSL signing mess, I'd be happy to use it.
- elithrar 13y ago> Plus $50/yr for the certificate This is certainly no longer true. $7 for a cert from Namecheap (domain validated).
- _delirium 13y agoInteresting, I guess I need to change providers. I last used RapidSSL, which advertises itself as a "low-cost" provider at $49: https://www.rapidssl.com/buy-ssl/ https://www.rapidssl.com/buy-ssl/
- jonknee 13y agoInterestingly you can buy the same RapidSSL certificate through Namecheap for $9.49. I'm not sure why they allow resellers to undercut them so dramatically, but I have been using Namecheap's version for years and the savings add up. https://www.namecheap.com/ssl-certificates/geotrust-ssl-certificates.aspx https://www.namecheap.com/ssl-certificates/geotrust-ssl-cert...
- 13y ago
- sukaka 13y agoAccount activity should also be a must for your users. Session id will not be as useful when users can monitor their accounts. It's a work in progress, but I'm writing a page on good application login design https://tagsauce.com/docs/designsnippets https://tagsauce.com/docs/designsnippets
- declan 13y agoThat's not true. Let me give you an example from mobile app development. As many of you know, Amazon's CloudFront lets you make an in-app connection to cdn.example.com, which may be a DNS alias for something like drj6nl5tupx60.cloudfront.net. Amazon will generate a cache hit or miss and, if not cached, connect to your example.com servers. The ideal way to do this is to generate an SSL certificate for the CloudFront distribution, but Amazon charges you $7,200 per year for that privilege: http://aws.amazon.com/cloudfront/pricing/ http://aws.amazon.com/cloudfront/pricing/ So if you want to load non-private images, video, etc. content via HTTPS from cdn.example.com via SSL without giving Amazon $7,200 a year, there will be an invalid certificate chain error. Some app development environments (not pointing any fingers right now in hopes this gets fixed quickly) do not support bypassing SSL certificate checks. So in some cases the answer is not to deploy HTTPS. :(
- nitrogen 13y agoSome app development environments (not pointing any fingers right now in hopes this gets fixed quickly) do not support bypassing SSL certificate checks. So in some cases the answer is not to deploy HTTPS. :( Wouldn't it be better to be able to specify a set of accepted key fingerprints, instead of bypassing security checks altogether? Outright bypassing security checks will make MITM too easy.
- 6cxs2hd6 13y ago> *The ideal way to do this is to generate an SSL certificate for the CloudFront distribution, but Amazon charges you $7,200 per year for that privilege: http://aws.amazon.com/cloudfront/pricing/ http://aws.amazon.com/cloudfront/pricing/ Maybe using SSL as an opportunity for a premium price gouge was smart business practice in the 90s. But these days, it's wrong. Charge for the actual cost. Even add your customary markup. But not some arbitrary $7200 fee. It may be legal, but it's unethical. Until they change it, Jeff Bezos and Werner Vogels should be ashamed of doing this.
- rschmitty 13y agoWhat's wrong with using the https on drj6nl5tupx60.cloudfront.net? Honest question.. no one is going to notice if they are getting assets on cdn.company.com vs drj6nl5tupx60.cloudfront.net, right?
- crazygringo 13y agoWhy on earth would I serve a blog of lolcats over HTTPS? Or really any site that doesn't involve logins, passwords, accounts, or sensitive data of any kind?
- deleted 13y ago[deleted]
- vacri 13y agoPresumably your lolcat blog still has an admin login, and in the spirit of the first part of the article, even this would be HTTPS'd.
- rakoo 13y agoI, as a potential target for Mitm, would like to be sure that what I'm accessing is your blog, and not some phishing crap.
- rythie 13y agoISPs or anyone could still insert malicious javascript into your site, or present download buttons or login features on your site. Visits to your site could be logged by IT departments, getting your users in trouble. Also I've actually heard of places where port 80 is actually blocked by default (but 443 isn't) and you need permission on a site by site basis to get it unblocked.
- dredmorbius 13y agoI've actually heard of places where port 80 is actually blocked by default That's impressive.
- willnorris 13y agobecause if security and privacy is only limited to sensitive or controversial sites, then the use of security and privacy become suspect. If ALL internet traffic were encrypted, it would make surveillance that much more difficult because you can't find the signal in the noise. Cory Doctorow's book, Little Brother, talks a bit about this... in fact, that book was one of the motivations for Google starting to encrypt web search traffic years ago. (more of my own writing on the topic: https://willnorris.com/tag/https https://willnorris.com/tag/https)
- mcherm 13y agoThank you. I came here to say this. Reasons NOT to use SSL: * Server is not powerful enough to handle the extra compute load -- SOLUTION: go buy a server made in the past decade. * Certificate costs too much -- SOLUTION: go get a free one. * You hope caching will reduce the load on your servers -- SOLUTION: pay for a CDN or use bittorrent for distribution. Mostly, mid-network caching doesn't happen anyway. That leaves just one reason: * You want 3rd world spy agencies and hackers to be able to snoop on and hack your customers just like the NSA can.
- lsh 13y agoI have dozens of unique domain names to secure and growing. The cost of buying an individual cert for each one is prohibitive. What can be done instead?
- klapinat0r 13y agoIf they have to be SLD then there's not really anything you can do as to avoid the number of individual certs. In terms of cost two obvious choices arise: * Maybe look into becoming a cert reseller? * Make your own CA. You could then bundle, but you'd still need the individual certs either way.
- finnn 13y agoThere are some CAs don't charge for certs, so unless you want an EV cert or something silly, them?
- lsb 13y agoNo it's not, it's literally $0. https://startssl.com/?app=1 https://startssl.com/?app=1
- liotier 13y agoExcept for anything that might actually involve liability. Put "shop" in the domain for which you want a free certificate and you will have it rejected by Startssl.com
- lsh 13y agothat was helpful making a decision, thankyou.
- dangrossman 13y agoTheir free cert is for non-commercial use only per their terms of service / certificate policy.
- duncanawoods 13y agoI recently tried the free startssl cert. Fine on IOS/OSX/W7 Chrome/Safari/Firefox/IE but it was rejected by Android default browser where startssl must not be a known CA. I don't think I can do without Android.
- herge 13y agoWhat about a CMS for, say, a blog? You want the administration console to be protected with https, but what about the main pages? Could I make admin.mydomain.com (and have the admin console on that) https only and my domain.com http? I don't want to buy a cert for the site, but I'd be happy to create a self-signed cert for all the people who can access the admin.
- GeneralMayhem 13y agoIANASE, but that should work, so long as you're diligent about keeping everything that requires a login quarantined to a separate subdomain. Once you leak a cookie over to the public side, it's over.
- Nick_C 13y ago> self-signed cert for all the people who can access the admin. This is what I do. The browser generates a warning on first use, and I then put the domain in the "ignore" list (since I trust my own domain). After that, it works fine.
- aioprisan 13y agoMost eCommerce sites do not deploy SSL site-wide, but only on login and checkout actions. Look at Amazon, Wayfair, etc. Depending on how the site was coded, you can mitigate session hijacking over HTTP. I'd love to see examples of Amazon session hijacking because product browse pages are simply over HTTP, I think you'll find that it's not possible to hijack those sessions.
- aeon10 13y agoI've noticed this too. Alot of ecommerce sites use HTTP for browsing. I assume this is because of speed. However I dont see why the session cannot be hijacked? If i copy all of the cookies how will the server differentiate the hijacker from the user. They both have the same cookies.
- aioprisan 13y agoCookies can be encrypted and changed with every page load, verifying sessions server-side. Session tokens can expire on every page or x-seconds and re-issued by the server.
- velis_vel 13y ago> If i copy all of the cookies how will the server differentiate the hijacker from the user. They both have the same cookies. If you set the cookies to be HTTP-only then you can't get at them from malicious JS.
- rythie 13y agoI think you just need one HTTPS only cookie (Amazon seems to have two) and just check that one (in addition to the others) at purchase time, since that one can't be stolen. However, the sign in button is served from a insecure page, so a ISP could MITM that and get your password anyway.
- aioprisan 13y agoit's easier to just hijack DNS anyways
- aeon10 13y agoAlot of ecommerce sites (Amazon, Flipkart) seem to use HTTP over HTTPS. Even when you're logged in. These sessions can easily be hijacked. I assume this is because of the handshake latency of HTTPS. Is there no way around this latency to make your website feel faster? I imagine there isnt, because even amazon uses HTTP.
- joevandyk 13y agoamazon uses https for any important/sensitive pages. there's two sessions, one for http, one for https.
- IsTom 13y agoWhat if HTTP page is mitmed and links to secure pages are replaced to point to somewhere else? It's all or nothing.
- mro 13y agoWhat if DNS is mitmed?
- ars_technician 13y agoNo one cares as long as you are using HTTPS, which is the point. If you aren't using HTTPS for all of your site, you are vulnerable to MITM attacks.
- troels 13y agoPresumably, the browser still needs to interrogate dns even if it talks over https, no?
- jholman 13y agoSure, and this is what HTTPS certificates from a CA are for. If your users are willing to click through the "warning: self-signed certificate" popups, then they're vulnerable, of course. But if they don't make that mistake, then your DNS result is reliable unless someone compromises the CA. Of course, CAs do get compromised. Or did I miss the point of your comment?
- elchief 13y agoDon't forget to disable TLS compression and HTTP compression for pages containing session ids or CSRF tokens. Basically you need a cookie-less HTTPS subdomain for your static media, and a www.example.com HTTPS domain for your content.
- yajoe 13y ago> Don't forget to disable TLS compression and HTTP compression for pages containing session ids or CSRF tokens. Dumb question: Is this general advice or is it specific to django due to the "BREACH" [1][2] https attack? It's not clear if it the underlying flaw is in using a CSRF token or something specific to django's implementation. I had never heard this before, so thank you. [1] http://news.softpedia.com/news/Django-BREACH-Attack-Against-HTTPS-Can-Be-Used-to-Compromise-CSRF-Protection-373647.shtml http://news.softpedia.com/news/Django-BREACH-Attack-Against-... [2] http://stacks.11craft.com/what-is-breach-how-can-we-protect-django-projects-against-it.html http://stacks.11craft.com/what-is-breach-how-can-we-protect-...
- elchief 13y agoGeneral. Don't use TLS compression or HTTP compression for any information you want to keep secret. BREACH and CRIME attacks exploit this. You can still use, say, HTML minification. You can compress your js and css as long as you make sure you aren't sending your confidential information in those request/response headers. A good way to do this is to setup a subdomain for media that never uses cookies.
- yajoe 13y agoThanks. We've been segregating authenticated vs non-authenticated traffic to different domains for a few years now (we had the same realization as moot), but I was unaware about this specific exploit related to TLS compression. That said, it seems on nginx TLS compression was not enabled by default, so we are ok (for this known vulnerability).
- jvehent 13y agoThat's a good beginners guide. To take it a step further, check out the documentation that we maintain at Mozilla: https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS
- dguido 13y agoYou should consider combining CipherScan and SSL Labs into a Tools section, then adding SSLyze. It does nearly everything SSL Labs does from the command line: https://github.com/iSECPartners/sslyze https://github.com/iSECPartners/sslyze
- herge 13y agoAlso check out the "Quick Wins for Better Website Security" talk that Dan Callahan (hey, I wonder where he works) at PyCon Canada. https://speakerdeck.com/pyconca/quick-wins-for-better-website-security-dan-callahan https://speakerdeck.com/pyconca/quick-wins-for-better-websit...
- callahad 13y agoHah! Thanks! I'll also be giving an updated version of that talk at PyCon in Montreal this April. :) There's a video of the PyCon Canada talk here: http://pyvideo.org/video/2315/quick-wins-for-better-website-security http://pyvideo.org/video/2315/quick-wins-for-better-website-...
- drcode 13y agoAnyone know of a good ACTUAL guide for deploying HTTPS? i.e. ins and outs of different certificate types, configuring on popular backends, etc? I always have to stumble through this painfully every time it comes up again.
- deleted 13y ago[deleted]
- myvii 13y agoBest practices guide at: https://www.ssllabs.com/projects/best-practices/index.html https://www.ssllabs.com/projects/best-practices/index.html More technical wiki with configurations at (already mentioned): https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS
- im_a_lawyer 13y agoyou are pathetic
- notastartup 13y agoside question: how do you make your blog entry like the Medium.com style? It's very easy to read this blog.
- bastawhiz 13y agoThe biggest barrier to HTTPS is the fact that it's a royal pain in the ass for someone who's not an OPs guy to set up. Unless you're on a shared host or some sort of PaaS that sets your certificates up for you, it's basically a big "go fuck yourself" to get everything installed and configured properly. Even the Mozilla article linked in the top comment asks you to choose a ciphersuite. Who the heck has time to know and understand what to use, and then figure out how to make it work on their own server? Oh, the version of Apache you're running combined with the version of OpenSSL that comes pre-installed on your Linux distro causes "Re-negotiate handshake failed" errors? Good luck finding the answer to that on StackExchange. For most folks that are just trying to ship something, unless security is a huge issue HTTPS doesn't come first because it's simply too much work. And if HTTP works out of the box, there's little incentive to turn on HTTPS.
- curiouslearn 13y agoI concur. I wish it were easier to setup.
- velis_vel 13y agoI was able to get basic SSL working with basically no effort just by Googling around for 'SSL nginx'; the Mozilla article doesn't tell you to choose a ciphersuite, it tells you 'use this one unless you know what you're doing'. And then if you scroll down it gives you some configuration directives you can just copy-paste into your browser config file. I'm not even an ops guy and I was able to get it working for my (granted, fairly simple) site without any pain.
- bad_user 13y agoIf you want another reason for enabling HTTPS, even for shitty blogs - on one of my visits to the US, I stayed at a motel that was snooping on my Wifi traffic, injecting their own ads in Google's searches and displaying their own banners in the websites I was visiting. If you're the owner of a Wifi network, there are already available solutions for monetizing users' traffic, by injecting ads, like this one: http://rgnets.com/ http://rgnets.com/ So you, as the publisher of a shitty blog or website, do you really want ISPs, motels or any other third-party to mess with your own content, to inject their own scripts and frames in your HTML, to degrade the experience for your readership? One easy way of fixing that is HTTPS. HTTPS is not just for security or privacy, it's also for digitally signing the content that's being served.
- waps 13y agoHere's my guide for when to enable HTTPS : Always. You're just adding one more reason. Anybody can do this if you're not using https (with real certificate).
- Sami_Lehtinen 13y agoHttps doesn't stop them, mitm solves the problem for them. I'm sure you have already seen it, if you travel a lot. It's bad idea to redirect http to https. It's much better to drop http support completely. Redirection weakens security.
- flyt 13y agoThis is why we have HSTS.
- Sami_Lehtinen 13y agoAnd secure cookies, yes. But as we have seen, those things simply do not work out. As the usual layered security approach, it's good idea not to provide HTTP service at all, so redirection isn't hiding failures to use HTTPS.
- bad_user 13y ago
- shmerl 13y agoWhen? Always.
- fdomig 13y agoI think there is absolutely no reason to NOT deploy HTTPS.
- wepple 13y agoI'm a little surprised such a basic article has made it to frontpage of HN, and especially considering a number of omissions - such as that Cookies should be marked with a 'secure' flag when using HTTPS, or that weak ciphers should be explicitly disabled. There's no "we're ok, I switched security to ON" in the security world
- callahad 13y agoDid we read the same article? The `secure` flag is the fifth of the "Key Points" at the top of the article, and the entire penultimate section is devoted to it.
- yeukhon 13y agoShould internal communication also be HTTPS? Even if they are sitting behind your powerful firewall, should they be HTTPS with some valid certs?
- nvr219 13y agowhen=always
- jeroends 13y agoDoes anyone know if it would be completely save to have a site (blog) with the public part on http:// http:// on one domain (f.e. aa.com), and the administration part on https:// https:// on another domain (f.e. bb.com)?
- HNLogInsSuckAss 13y agoUseless. Where was the "HOW"? Why is this on the front page?