Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why don't we see more HTTPS? Is CPU an issue?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Ask HN: Why don't we see more HTTPS? Is CPU an issue?

#21

Post by jhancock »

For most startups, the performance hit is not a big deal. If your a serious startup, you need your own IP, so this shouldn't be a roadblock. Setup is not hard. If you can't setup an SSL cert, how are you going to manage the rest of your server concerns? Cost of the cert? This is a drop in the bucket compared to the rest of your startup.

For most, the big problem is the all or nothing decision. Most end users don't like the browser asking about switching protocols, for example, for the login or credit card process. So the easy choice is to use https for everything. But that's a waste, most of your requests don't need it. But there is lots of waste that buys you value: ruby, multi-layered frameworks and libs, etc.

Re: Ask HN: Why don't we see more HTTPS? Is CPU an issue?

#22

Post by scumola »

Most larger companies have an "SSL Accelerator" which is usually part of a router/switch/load-balancer. This device does SSL in hardware, so it can do the offloading much faster and let the web servers and app servers worry about serving-up the app and doing that work. Most SSL Accelerators can do millions of connections without working too hard, so it's possible at large scale for larger websites without really worrying about CPU on the server-side. I'll bet that they just don't worry about SSL except for when it's absolutely necessary (personal info - login, purchase, ...).

Re: Ask HN: Why don't we see more HTTPS? Is CPU an issue?

#23

Post by bensummers »

kdw wrote: post #15
donw wrote: post #8

Earlier quoted context omitted.

If you're like most newer startups that have their customers under a TLD (foo.mycorp.com, bar.mycorp.com), you can use wildcard SSL to manage the problem. Otherwise, yeah, you're looking at one IP per TLD.

Am I correct in thinking that a wildcard only gets you one level deep? e.g. that *.mycorp.com matches "foo.mycorp.com" but not "foo.bar.mycorp.com"?

Depends on the browser, which in practice means just one level deep.

Re: Ask HN: Why don't we see more HTTPS? Is CPU an issue?

#24

Post by axod »

adamt wrote: post #13

Why though - would anyone want to browser a site like news.ycombinator.com over SSL? The vast majority of web data is public data so encryption is of little value, and due to the way SSL works, then there's arguably little value in SSL for authentication (if someone can hack the site, they can generally apply/install for a new SSL cert easily enough). In terms of privacy, SSL gains little - given that SSL breaks Host…

>> Breaks any web-caching by a proxy

This is actually a pretty great upside often. Using SSL means that you can be reasonably sure that nothing is messing with your data in transit - caching, modifying, etc.

Free wifi that modifies html pages and adds adverts? Just use ssl instead.

Some firewalls that block based on keywords in pages etc - use SSL instead.

Re: Ask HN: Why don't we see more HTTPS? Is CPU an issue?

#25

Post by wglb »

adamt wrote: post #13

Why though - would anyone want to browser a site like news.ycombinator.com over SSL? The vast majority of web data is public data so encryption is of little value, and due to the way SSL works, then there's arguably little value in SSL for authentication (if someone can hack the site, they can generally apply/install for a new SSL cert easily enough). In terms of privacy, SSL gains little - given that SSL breaks Host…

If I am reading stuff at the library or other public wifi (says right hear "The Library's wireless network is not secure") I don't want eavesdroppers to know.

Re: Ask HN: Why don't we see more HTTPS? Is CPU an issue?

#26

Post by tessro »

tsally wrote: post #20
tessro wrote: post #4

Earlier quoted context omitted.

Single-domain certificates are cheap. RapidSSL charges $79/year, and you can do better. Wildcard certificates have come down as low as $200 a year, very recently. The price issue is mostly perception at this point, but like they say, perception is reality. I would gamble that most people don't realize how much cheaper SSL certification has become.

It's not the cost of the certificate that's the issue. It's the SSL bandwidth overhead.

Good point, I had not even thought about that angle.

Re: Ask HN: Why don't we see more HTTPS? Is CPU an issue?

#27

Post by revicon »

trezor wrote: post #5

For HTTPS you need a dedicated IP since security negotiation happens before the HTTP hosts header is posted and your cert needs to cover the host you want to connect to. That is, it is impossible to host several sites using HTTPS on one single IP. HTTPS using SSL (instead of for instance TLS) means that this is a limitation built into HTTPS itself and can't be mitigated. With the current shortage on IPv4 IPs and most…

Reading everyone's reasons for not implementing SSL, I'm wondering, how do you handle user logins? I'm building a site right now, and I need to create user accounts, and allow them to login with a username/password. Seems irresponsible to have them pass their password as cleartext when they log in. What do you do instead?

Re: Ask HN: Why don't we see more HTTPS? Is CPU an issue?

#28

Post by lucumo »

donw wrote: post #7
tessro wrote: post #4

Earlier quoted context omitted.

Single-domain certificates are cheap. RapidSSL charges $79/year, and you can do better. Wildcard certificates have come down as low as $200 a year, very recently. The price issue is mostly perception at this point, but like they say, perception is reality. I would gamble that most people don't realize how much cheaper SSL certification has become.

I agree that it's all perception, and that even with wildcard SSL at $500/year (what the cost has traditionally been), it's worth it to protect your customers' data. What scares me are companies that allow a front 'login' page on a non-SSL domain, and have everything else on their domain name via https, allowing for easy man-in-the-middle attacks.

> I agree that it's all perception, and that even with wildcard SSL at $500/year (what the cost has traditionally been), it's worth it to protect your customers' data.

I suppose that depends on the data. $500 keeps one of my servers running for 6 months. For a bank the security is very useful. For a site like HN where the only sensitive data is the password, it isn't so much.

Re: Ask HN: Why don't we see more HTTPS? Is CPU an issue?

#29

Post by adamt »

wglb wrote: post #25
adamt wrote: post #13

Why though - would anyone want to browser a site like news.ycombinator.com over SSL? The vast majority of web data is public data so encryption is of little value, and due to the way SSL works, then there's arguably little value in SSL for authentication (if someone can hack the site, they can generally apply/install for a new SSL cert easily enough). In terms of privacy, SSL gains little - given that SSL breaks Host…

If I am reading stuff at the library or other public wifi (says right hear "The Library's wireless network is not secure") I don't want eavesdroppers to know.

Even with SSL though, an eavesdropper would know:

a) What site(s) you were accessing (the IP address is visible, and as it can't be a shared IP, a DNS lookup or SSL connect to that site should give them what site) and the length of time on each site. b) The approximate size of those pages, and the number of embedded items, so could quite probably and within reasonable time know what pages. c) If they knew your browser (through seeing non SSL traffic) they could probably know the length of the URL.

Have you really gained anything through using SSL??

Re: Ask HN: Why don't we see more HTTPS? Is CPU an issue?

#30

Post by wglb »

adamt wrote: post #29
wglb wrote: post #25

Earlier quoted context omitted.

If I am reading stuff at the library or other public wifi (says right hear "The Library's wireless network is not secure") I don't want eavesdroppers to know.

Even with SSL though, an eavesdropper would know: a) What site(s) you were accessing (the IP address is visible, and as it can't be a shared IP, a DNS lookup or SSL connect to that site should give them what site) and the length of time on each site. b) The approximate size of those pages, and the number of embedded items, so could quite probably and within reasonable time know what pages. c) If they knew your browse…

They don't see the content coming or going. That to me is pretty significant.
Post reply on HN