7 ms·
Q: When to deploy https? A: Always.
by njharman 13y ago
Q: 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.