Why Doesn't Every Website Use HTTPS? 665
suraj.sun writes "HTTPS is more secure, so why isn't the Web using it? You wouldn't write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection that's essentially what you're doing. There is a better way, the secure version of HTTP — HTTPS. But if HTTPS is more secure, why doesn't the entire Web use it?"
Haven’t we been here before? (Score:4, Informative)
I’m no HTML technician, however I would assume it requires significantly more processing power. Your personal blog or website with 10 hits a day sure, run it over https and you probably wouldn’t notice much difference (aside from the cost of your own unique IP address). A large scale site however would probably have more hardware and bandwidth requirements to implement https on everything.
And I don’t think it’s laziness. A lot of sites will do the login and purchasing bits over https, and have the rest of the site regular old http. It’s probably more effort to do this kind of mixed environment than just make the whole damn thing over https. The only reason for this that I can see is if there was a significant cost associated with encrypting everything un-necessarily.
Correct (Score:2)
Yep, the one-line answer is:
It's too CPU-intensive for the server.
Cost could be an issue but it's like $100 a year? Hardly a problem for anything but the most amateur of blogs.
Re:Correct (Score:5, Informative)
Re: (Score:3)
You're talking about UCC certificates [godaddy.com], and yes, they've been around for a while. The problem is browser adoption - there are still waaay too many people using IE6 out there.
Re: (Score:3)
Re:Correct (Score:5, Informative)
Also, HTTPS does not play well with proxy caches or load balancing.
Re:Correct (Score:5, Interesting)
Also, HTTPS does not play well with proxy caches or load balancing.
This is the main reason we have not been implementing it. Our environment relies heavily on caching and loadbalancing. We are trying to find ways around it though, especially to get all session-data to use HTTPS (but a requirement is that users are not scared with warnings about part of the content being unencrypted).
Re:Correct (Score:5, Informative)
Re: (Score:3)
Yes, you can configure a proxy server (squid, pound, varnish, etc) to cache SSL content. However, client browsers don't and won't.
Re:Correct (Score:4, Insightful)
True.
Even with the mighty Google I can see the lag while using the secure version. And secure Wikipedia version stops working sometimes. Hell, I'm writing this on a website without HTTPS, maybe /. web masters could answer why is it like that, too.
No, that's not right at all... (Score:3, Funny)
The correct answer is that since everybody chooses either "password", "123456" or "iloveyou" to guard their life secrets then there's no point in encrypting anything.
Re: (Score:3)
Protip: If users don't give enough of an airborne copulation at a ventrally rotating pastry to choose passwords that aren't brain-meltingly stupid, then they don't care about encrypted transport to/from the web servers, and there's no point in eating the added costs
Re:Correct (Score:5, Insightful)
But as we've seen proven, the CPU load isn't as big of an issue as is claimed.
The reports where people said it was, were from an awful long time ago, discussing high loads and CPUs that were measured in Mhz (i.e., Ghz CPUs weren't even imagined yet).
Right now, we have to look at a few issues.
1) Users are familiar with typing http:/// [http] . If you went https only, without a redirection from http:/// [http] you'd lose traffic. Simple fix, do a redirection.
2) Not everyone supports https still. If you include a piece from a 3rd party, you'll either get a broken lock, or the 3rd party data won't show.
3) Google Adsense doesn't support it. Still. And people have been asking for years. They are a major revenue source for a lot of sites.
4) Hosting https sites still require a unique IP for each site. If I, a a hosting provider, have 1000 sites on a server, I'd rather use one IP, than 1000 IPs.
5) SSL certs must be renewed. You must have the cooperation of the provider. Certs are no longer $100/yr, if you shop around a little. Trustico [trustico.com] has provided perfectly functional certs for $20/yr for a long time (with discounts for multi-year purchases). I've been using them for several years. For a blog that has very cheap hosting, even the $20 doesn't necessarily make sense.
6) The time where there were huge compatibility issues with SSL implementations in browsers is gone, but you will still find the occasional app that doesn't have SSL compiled in by default, but that has become rare. At very least, all modern browsers support https:/// [https] out of the box, regardless of where you are at.
The biggest issue is, users don't generally care. On my site, I have a warning every page if you're viewing insecure, and encouraging you to click the link to switch to the https version. Less than 10% of the users ever switch up to the https version. The only time I enforce it is when a users logs in. When they try to log in, it forces them to https, and keeps them there for the duration of their session.
Re: (Score:3, Interesting)
On point #4, it's been awhile since I played with webserver setup, but SSL certificates for public sites are usually tied to the server DNS name, not its IP. I'm pretty sure this means you can have more than one webserver/hostname entry, all with the same IP, and use host header names (IIS) or Name-based Virtual Host Support (Apache/others) to determine which site and certificate to connect the user to.
There's still the occasional hiccup in recognizing certificate authorities, even big ones. My cell phone c
Re:Correct (Score:5, Informative)
Re: (Score:3)
Re: (Score:3)
Please see:
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts [apache.org]
Re:Correct (Score:5, Funny)
Hey...1998 called
Oh man! Did you warn them about the World Trade Center [xkcd.com]?
Re: (Score:3)
> 1998 called? Did you warn them about 9/11?
I did. They already knew about it. :-)
Re:Haven’t we been here before? (Score:5, Insightful)
If you are going to switch back over to http, you might as well not bother in the first place. HTTP, being stateless, one need only sniff that session ID, and they are now in. That so-called webmasters think they are guarding access by only encrypting/authenticating the login amuses me.
Re:Haven’t we been here before? (Score:5, Insightful)
"That so-called webmasters think they are guarding access by only encrypting/authenticating the login amuses me."
..which is why you need to let real webmasters get on with it and not try it yourself. We are protecting -something-; it's your loss if you cannot work out what that is.
Re: (Score:2)
I would assume in cases like this, they set the SSL bit in the cookie and do whatever web voodoo is necessary such that the cookie gets sent over ssl.
Then again, I've seen some pretty boneheaded stuff security wise on the web... maybe they don't!
Re:Haven’t we been here before? (Score:5, Informative)
You cannot depend on the user's IP address not changing. Besides offering only some additional security (most people subject to having their session sniffed are using the same public WiFi as the user - so they'll actually have the same IP address), more importantly, some users have load-balanced outbound Internet access.
On our own network, we see legitimate single sessions bridging multiple A-class networks. Page request to page request they will have an IP address from a wholly different ISP, which can even geolocate to wildly different locations. Admittedly that's the exception rather than the rule, but it's also becoming more common - especially for people on mobile networks, whose IP address is subject to whichever cell tower is giving them the strongest signal right now. Users sitting relatively equidistant from multiple towers can flip between various IP's rather frequently.
The only things you can reliably depend on not changing in the user's request (for legitimate users) are also all spoofable by illegitimate users. For example, you can depend on a cookie not changing unless you told it to change, but it can be spoofed; you can depend on the user agent not changing, but it can be spoofed, and so forth.
There is no way to make an unspoofable session cookie; you can only prevent interception by using a secure standard such as SSL.
Re: (Score:3)
I think you missed the point. Not only does it fail to provide any protection in the most likely interception scenario, but for that lack of protection, it also breaks the site for legitimate users. A little added security for no user inconvenience is ok - as long as you're realistic about the small protections it offers, but it's decidedly less ok when real users find they're unable to use your site as a result.
You can make it harder to pick the locks (sniff session tokens) by nailing your front door shu
Re:Haven’t we been here before? (Score:5, Interesting)
Obviously, that does nothing to prevent assorted public-wifi hilarity; but it makes it comparatively difficult(difficult enough that social engineering or just guessing that the password is 'password123' because they always are is easier) to permanently compromise the account and generate a customer support/being flagged as a spam host cost problem.
Webmasters who think that this is actually good security are fools. Webmasters who think that it blocks a certain class of especially costly attacks, while being much cheaper than full HTTPS, are entirely correct. And, given how little one pays for access to many sites that do this, they probably don't care too much unless something attracts mainstream attention *cough*firesheep*cough*...
Re:Haven’t we been here before? (Score:4, Informative)
Re: (Score:3)
They may not be guarding access, but they are guarding against an eavesdropper discovering the password. Sure they can session hijack after switching back to HTTP, but they don't have the password. This fact could be leveraged further by requiring the user enter the password (and transition to HTTPS again) whenever something important like changing password, email, or making a monetary transaction is done.
That said, I do agree that switching back to HTTP while still logged in is still a bit silly.
Re: (Score:3)
Actually, the main reason why the password is https but the session ID is not so important is because people recycle their passwords, and session ID's are merely temporary. So it is sensible to keep a user's actual password encrypted, but not worry about the session if there is little to do other than browse the catalog or post a comment. Whenever any action requiring HTTPS such as final checkout is called up again, then often a good site will ask for the password again and not trust the session ID from HTT
Re: (Score:2)
This. Lots of page accesses = lots of processing power spent on encryption and decryption. Not everyone can afford hardware cards to do the encryption.
Second, proper certificates costs money, and you "kind of" need one static IP for each website - it's a big hard for a person to justify the need for one IP for each of his 10 blogs - most companies will only issue a block of 8 IPs (5 usable) to a single server.
Re:Haven’t we been here before? (Score:4, Insightful)
Server Name Indication has been supported by major browsers for 4 years. Browsers have supported Subject Alternative Name certs (which bypass the need for one IP per name) for nearly 8 years. At this point, the one cert per IP issue should be well addressed.
Re: (Score:3)
IE6 doesn't support HTML. It supports HTLM6 and is only used within corporate networks to access HTML6 legacy apps.
For browsing HTML on the public internet, these people need to run an HTML browser. So no problems there.
Re:Haven’t we been here before? (Score:4, Informative)
Actually no version of IE (that means 6, 7 or 8 or Safari) on Windows XP supports SNI. :-(
They use the system library, it does not use SNI.
Re: (Score:3)
The cost of the SSL certificate to make the HTTPS work has been the most common issue I've ran into. Penny-pinching administrators can't be convinced it's a justifiable expense. And they nickel and dime you for every service the certificate is "good for" such as email.
Static IP addresses aren't a problem, one IP can host a variety of completely different domain names, the server sorts out the requests based on the entire URL being requested, including the domain name. And there's nothing that says that y
Re: (Score:3)
You don't need a separate IP for each domain. The apache web server can have multiple sites on one IP, each with a different SSL certificate. It just decides which site and certificate to use based on the site name in the http request.
How is that possible since the Host: header is hidden in the SSL stream and the web server can't accept and decrypt the SSL request until it has the right certificate.
Re:Haven’t we been here before? (Score:4, Informative)
It's called SNI (Server Name Indication), it's part of the SSL standard, and has been supported in Apache since 2.2.12. The virtual host name is submitted as part of the TLS negotiations so the server knows which certificate to use.
Re: (Score:2, Informative)
Most websites are virtual hosts on a single server. SSL does not support more than one certificate per IP address/port.
Re: (Score:2)
1) Isn't SSL done on a per domain name basis?
2) Can't virtual hosts be NATed or something and each domain given it's own private IP address?
Re:Haven’t we been here before? (Score:4, Informative)
1) Isn't SSL done on a per domain name basis?
"HTTPS" is more or less setting up a SSL link and running plain ole HTTP over that secure link.
No the SSL encryption layer is done before the HTTP layer does it's thing. So if you identify your vhost as part of the HTTP header, then you're not going to know your vhost name until after the SSL is already set up and working, classic chicken and egg problem.
HTTPS/SSL a good argument for going ipv6 where there is no particular shortage of ip space.
Re:Haven’t we been here before? (Score:5, Informative)
Isn't SSL done on a per domain name basis?
No. But yes. Well, probably not quite yet.
No: The way HTTPS works when the "recent" SNI feature is not available is that the TLS stream is created (including certificates being negotiated and verified) before any hostname information is transferred. This means that you can only have one valid certificate per publicly addressable IP address without SNI.
But yes: With SNI (see http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org] for info) the hostname is sent earlier, so the server can lookup the right certificate for that name and send it instead of relying on a 1-to-1 mapping between IP addresses and service names.
Well, probably not quite yet: Unfortunately SNI is not completely supported by all common user agents, particularly any version of Internet Explorer running on Windows XP, so whether you can justify using the feature right now depends a lot on who your target audience are. If you don't have any users browsing your content/app with XP+IE or you don't mind telling such users to upgrade to FF/Chrome/other, upgrade Windows, or just put up with the certificate warnings, then using SNI will work for you. You run the risk of sending XP+IE users away though, which might not be acceptable if your bottom line relies on getting as much traffic as possible through your doors.
Re: (Score:3)
Speaking as someone who has run more than one SSL site on one host, you're correct. You open separate ports. Our method of choice to make those into non-ugly addresses was to
1) get the cert for a nice name like www.bleh.com
2) Create a Netscaler/F5/whatever SSL VIP that load balances webhost.bleh.com:9999 and webhost.bleh.9998, etc and presents it as one IP address on port 443. Make sure that each webhost httpd is using the cert for www.bleh.com. Also, you can load the SSL cert on the load balancer usual
Re: (Score:3)
Re: (Score:2)
It used to be noticeably slower to access a site via https than by http, even accessing the same page.
However, now we have server processors which operate in the GHz, and which run in multiples. Heck, we have that even for tiny home PCs and now phones. Servers are apt to be instances on clusters or clouds these days. So I don' think there is a major penalty for using https.
If your traffic is huge enough that you will notice the hit: then you really should be using https anyway. If you're serving that kind o
Re: (Score:2)
The article goes into this a bit. While crypto processing requirements are a small factor, the big deal really is the share-the-same-ip browser-reliant virtual hosting that people decided to use even though it was a crummy hack to start with. The Internet totally relies on it at this point. If you try SSL to such a site, there's no way for the server to choose the correct SSL certificate for the virtual host you are trying to reach -- because that information is not transmitted until the HTTP session is
Re: (Score:2, Insightful)
Except the sites that offer HTTPS are the highest traffic sites on the web: facebook, gmail, twitter.
You are dead wrong.
Other than the performance thing... (Score:4, Informative)
- For HTTPS to work seamlessly it requires a certificate signed by a trusted 3rd party, which usually (but not always) costs money. This would disadvantage smaller websites/businesses.
- HTTPS also (currently) requires a separate IP address per certificate. This would mean the current practice of hosting large numbers of domains on one IP using name-based virtual hosting would not be viable, which is something the shared hosting industry really relies on. IP addresses are also a very limited resource at the moment.
- HTTPS cannot be cached between the user's browser and the server. Even the user's browser uses more conservative caching which will further reduce performance.
Re: (Score:3)
To protect against a man in the middle attack. The certificate ensures you are connecting to the server at the end and not some intermediate or impostor that's relaying the messages or posing as the server.
Because that would provide no assurance that you are communicating with the server at the end and not some evil computer in between you and that server. It would make the
Re: (Score:3)
That's wrong. The following won't support support SNI.
* Internet Explorer (any version, even IE8) on Windows XP
* Safari on Windows XP
* Safari on Mac OS X 10.5.6
* Any browser on Android
* The browser on iOS 4
* The browser on Windows Mobile 7
* The browser on Blackberry
* wget
* Konqueror/KDE
It's gonna be a long time before we can consider using SNI. Wouldn't be surprised if IE8/WinXP hangs around for many years.
Certificate? (Score:4, Interesting)
Maybe because it requires certificates that cost money and annoy users when they expire?
Re:Certificate? (Score:5, Informative)
Free certs are available, and every bit as (in)secure as the paid standard ssl certs.
http://cert.startcom.org/ [startcom.org]
The "annoying users when they expire" is a symptom of the main problem.
Well, actually it's 2 problems.
For small hosters, IE(any version) on XP doesn't support SSL/TLS on virtual hosts. Everybody else does. http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org]
For large hosters, SSL key distribution and updates becomes a problem when using large server farms or CDNs. Doing SSL in hardware on load balancers solves this for server farms, while CDNs are a more difficult problem.
Those are the main reasons. Latency and CPU usage are not deal-breakers today, though they are a factor.
Re:Certificate? (Score:5, Informative)
The certs from StartCom are whatever you generate for them to sign. Last year they accepted 1024 bit RSA and 2048 bit RSA. LIke the rest of the SSL vendors, in 2011 only 2048 bit RSA certs are allowed for issuance, and full transition to 2048 only certs by 2013.
Secondly, the 128 or 256 bit symmetric crypto has nothing to do with the SSL cert or provider, that's software settings on the host. 128 bit AES is widely considered secure against attacks for the next 20 years or so, and 256 bit should be secure for the as far into the future as we can guess. http://www.keylength.com/ [keylength.com]
The (in)security I refer to has to do with the level of checking into who you are. Basically, they just send an email to administrator type address at the site you want a cert for, and if you get the email you are assumed to be the admin. This can be attacked easily through DNS flaws or just signing up for a webmail account with an address that the SSL provider thinks sounds like an admin account. This happened to many of the large webmail providers before they started blocking the common admin accounts for registration.
XKCD was right. The common attacks are against the humans who run your DNS or mail providers, not that the crypto is weak.
http://xkcd.com/538/ [xkcd.com]
And because IPv4 addresses are scarce (Score:2)
Re: (Score:2)
That's why I never got on the https bandwagon. I couldn't self-sign without generating error messages in the browser, and none of the content that I served at the time had any need to be secure. It was self-publishing, for crissake, effectively vanity publishing.
Come to think of it, so is everything on facebook, twitter, and most other websites, including this one. I guess it's not really important for almost anyone.
I have an idea- if you need something to be secure, don't use HTML or HTTP at all. Use a
Re: (Score:3)
This.
A lot of people don't realize that the SSL handshake takes place before the client sends the host field to Apache or IIS. The server has no idea what site you are requesting. That means that if you have a virtual server with 200 sites then only one of those 200 can have an SSL cert. Can "Joe's Webhosting" ask for 199 IP addresses? What if all small and medium hosts did that? We'd hit the IPv4 address limit faster than we already are doing.
Virtual hosting is the server side equivalent of NAT. Its large
Cost (Score:2, Informative)
Certificate costs -- you need a valid signed certificate to avoid mim attacks. There's more computational overhead too, and say goodbyte to virtual hosts (ipv4 addresses don't grow on trees)
Re: (Score:2)
Nowadays "real" certificates are not expensive anymore. Certificates from "Comodo" were in the past offered for as little as USD 5 per year. Currently they can be had to USD 9,95 for one year for example at www.litessl.de (Disclaimer: I'm not affiliated with this company but a happy company of their "main" operations under a different name).
While some SSL vendors try to put these cheap certificates into a bad light (because they are issued in a automatic process, certain data is not included into the certif
Re: (Score:3)
And regarding virtual hosts this problem has been solved as well, see http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org] This technology is still not universally available
A better URL is
http://en.wikipedia.org/wiki/Server_Name_Indication#No_support [wikipedia.org]
Its a good solution if you want to get rid of 50% + of your users.
Although theoretically you are correct that in a decade or so it will be a usable solution.
Re: (Score:3)
How is it Microsoft's responsibility that people are still using a ten year old operating system?
Calling XP a 'ten year old operating system' is hyperbole. Until Vista, it was the latest OS that Microsoft was shipping, so it's been under five years since there was a replacement available, four since Vista was available to the general public (January 2007). The system requirements for Vista were so high that it wasn't shipped with a lot of entry-level machines, especially netbooks. Microsoft was still shipping XP until January 2009 - two years ago.
So, it's not so much a matter of people using a te
Certs are a pain (Score:2)
For the company I work for it's because Certs cost money, and self-signed certs are a pain for users.
Re: (Score:2)
They aren't exactly expensive though. Slight pain in the ass to set up, but not that bad. I just use a self signed cert on our own site since it's only employees that need access to the private section.
Because getting a signed SSL certificate is $$$ (Score:5, Insightful)
Subject says it all. It's expensive to get a signed SSL certificate. If I'm not doing commerce through the website, and it's just a blog of some sort, I'm not going to pay extra money for a certificate when I'm not making any money off it. A self-signed cert is fine for personal use, and I use it for my webmail portal, but it doesn't exactly look professional, or even legitimate, to joe user out there.
*most* commercial websites do actually have an SSL cert for their e-commerce operations. For most, if not all, of the sites I ever use (except Slashdot), I can simply change the http to https and the site will work fine. But I don't really see the point in a website using https for anything that doesn't involve the exchange of personal or financial information. It's unnecessary overhead, and expense, for these websites. HTTPS does add extra sever load on their systems, you know. :)
Re: (Score:2)
You're kidding, right? You can pick up a single site SSL certificate for under $20 and a wildcard certificate for about $100. For all the other costs associated with running a website, the cost of an SSL certificate is negligible.
You don't need to be doing e-commerce to have data worth protecting. If nothing else, half your users probably use the same login and password for your site as they do for their email, their social networking and p
Re: (Score:3)
Maybe you should choose a provider which does not rip you off.
virtual hosts, money (Score:3)
1. it costs money to get an SSL from a recognised signing company
2. SSL for virtual hosts is not supported by Internet Explorer (yet another problem with IE)
Re: (Score:2)
Show an example of something properly configured that it doesn't work on please. If you do it properly, IE will have no clue you're serving sites based on host-headers.
Re: (Score:2)
The problem is that the SSL negotiation happens before the HTTP session begins so there is no Host header available when the server has to cough up a certificate.
There are really only 3 options for HTTPS virtual hosting:
1) Wildcard certificates if all the sites are in the same domain
2) SAN certificates if the certificate ifs purchased with up to 5 names on it
3) An extension to SSL called SNI that sends the host information in the SSL negotiation.
The OP is referring to the fact that SNI is far from universal
Re: (Score:3)
4) Run on multiple ports. URLs like https://example.com:23456/index.html [example.com]. This absolutely confuses the heck out of some firewall monkeys.
Re: (Score:2)
IE7 and newer, for the record, do support SNI; so long as you're on Windows Vista or Windows 7.
Because... (Score:3)
Another thing to go wrong (Score:2)
Re: (Score:2)
If this isn't a new meme I'm not aware of, my head hurts...
Cost-benefit (Score:5, Insightful)
Implementing HTTPS isn't quite as simple as just turning something on and walking away. For larger web-based infrastructure, the best practice involves use of SSL terminators to maintain performance at scale; the encryption load of doing SSL or TLS at the actual web server itself is a Very Bad Idea when you're handling a lot of traffic. But those devices are not cheap, and there's a substantial amount of effort in both architecting them into an environment and keeping them running well; it's like any other IT infrastructure, in that it adds cost and complexity. In some cases, other aspects of the environment would have to grow as well...if the IDS and/or IPS sensors, for example, wouldn't see traffic in that section that is 'in the clear' between the web servers and the SSL accelerators, the organization would have to decide between purchasing more of these (much more expensive) security devices and giving up visibility into attacks over what is likely their highest-risk bit of attack surface. For smaller sites, the complexity is lower but cost is a more significant factor, as (for much smaller sites) the challenge and uncertainty of maintaining certificates. And for what? For most sites I can think of, I would be hard-pressed to make a business case in support of ubiquitous SSL...why should the New York Times spend so much just to make sure someone else can't see what news I'm reading? Even if they sniff my account credentials off the wire, what harm could really be done with it that would justify the expense?
Simply put, it's not free, and in most cases, the cost of security would be greater than the cost of the risk being mitigated.
A lot of stuff doesn't need to be secure (Score:5, Insightful)
For instance, a large website where the primary goal is public commenting on interesting tech stories, or a public online encyclopedia - the whole point is that it's public, so encrypting it makes no sense.
And SSL encryption has a non-zero cost: it takes cycles to encrypt and decrypt on each end, and costs something to get a certificate.
long discussion (Score:3, Interesting)
Part of this was discussed long ago [slashdot.org], with browsers treating self-signed certificates worse than they treat plain unencrypted traffic, even when passwords are passed around in plain text, nothing will change, because it is a major PITA to deal with browser issues as well as with CAs.
Here is a hint: create more incentives to use HTTPS, not fewer, and more people will use them.
This is not going to be fixed until stupid browsers stop treating a new connection to a website, that is using a self-signed certificate as some sort of a virus, while absolutely not doing the same for plain HTTP connections.
But they're not unrelated... (Score:3)
THe problem is that the browsers persist under the myth that certs can ONLY be used for proving the identity of a host; and completely disregard the fact that an equally valid and completely unrelated task is traffic encryption.
The trouble is, identity checking and encryption are inseparable.
Public key encryption doesn't allow Bob to securely exchange data with Alice: it allows Bob to securely exchange data with someone claiming to be Alice who has given Bob what she claims to be Alice's Public Key.
Without some way for Bob to verify that the person claiming to be "Alice" is, indeed, the real Alice that's about as much use as an ashtray on a motorbike.
Where self-signed certificates are useful is when you've independently verifie
Why do certs cost $$$? (Score:2, Interesting)
This is something that has really bothered me.
I understand that a self-signed certificate is vulnerable to MitM... however, it's still better than plain-text! And we could be a little smarter about this too, couldn't we?
SSH is a perfect example. When you first connect via SSH, you confirm that you trust the certificate. Your client then remembers the certificate for future use. Why doesn't web technology do this?!?
Instead, when you self-sign a cert, browsers throw a hissy fit and shows a huge warning.
I
Re: (Score:3)
Re: (Score:3)
Actually, it's nowhere near as bad as everyone is making out. Sheesh, what a bunch of fussy fusspots.
You have a deliberate "mitm" (otherwise known as a proxy) that has ALL of the certs (or, indeed, just one cert, since the object is to encrypt traffic, not necessarily strongly authenticate it). It can be multi-homed or it can have virtual hosts, it really doesn't matter worth a damn. This front-end box then runs plain HTTP requests to the actual server(s) hosting the content within the network.
The advantage
It's XP's fault. (Score:5, Interesting)
Today one of the major reasons is that IE on XP does not support the SSL/TLS extensions for virtual hosting.
When he says,"it's only partially implemented" he means everywhere but IE(any version) on XP.
http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org]
SSL issues (Score:4, Interesting)
It's more expensive in terms of processing power, you add latency due to negotiation, you lose caching across sessions, moving the user across servers is not as easy, you lose some amenities like sendfile() support, you have to manage certificates, you have to buy certificates, and in most real-world settings it's a minor security improvement anyway because the biggest security issue is the user's own worm-infested machine.
Well lets see... (Score:3)
1) SSL certificates are not free
2) SSL key exchanges are horribly expensive compared with serving a web page
3) Right now EVERY web site would require a unique IP address
Enough reasons?
Some reasons (Score:5, Interesting)
Ok... In reverse order of significance:
1. Expense (at least traditionally) of SSL Certificates. Although today that's not such a big issue, and an SSL certificate costs about the same as your domain registration. However, if you have multiple subdomains you still need a more expensive certificate.
2. Complication. It can be a highly confusing process for someone who's not an expert to do the certificate request process and the associated installation of the certificate. I know the first time I tried to do it, it went horribly wrong and I spent a day trying to sort it out.
3. Client Performance: SSL websites are slower than non-SSL websites. Not such a big deal again these days, but I remember when I had to wait it would seem forever for the images on my online banking site to load, cursing them every time for such a graphically-intensive SSL site.
4. IP addresses: This is a big one, if you host multiple websites on your server, and you only have a single IP address, you can't host more than one SSL certificate. So you need more IP addresses (which is not easy nowdays). Big deal for small company hosted websites, which are often on shared IPs.
5. Server Performance: A server that can cope with one million users per day using HTTP will not be able to cope with anywhere near that number of connections over HTTPS for obvious reasons. So you not only need a certificate, you potentially need a whole new server architecture to deal with it. Scale this up for a big business like Twitter or Facebook and you're talking implementation costs in high millions of dollars.
slower on the wire, harder on the processor (Score:2)
of course, this was more of an issue when we were using 386s and 28.8kbps modems, so its more of a historical reason than a present-day reason
although, modern AJAX sites require low latency for a good user experience. HTTPS introduces latency. so there's a new technological issue why HTTPS all of the time won't necessarily take hold
mobile sites and smart phones, which are pretty much the future of the web, and which are growing in leaps and bounds in terms of bandwidth and processor power, are still subject
Named based Virtual hosting doesn't work via HTTPS (Score:2)
You can put 100's of websites on 1 IP address to virtual host... Kinda one of those evil things like NAT. Cheezy way to save IP addresses, but done very often.
The moment you turn on SSL you're locked to one IP = one website. Much less efficient.
As far as the old SSL = LOAD issues... the first thing I do in PHP on the sites I control is do a header forward to HTTPS.... Computers now can handle a lot more load.
Processing Power/Bandwidth/Expense (Score:2)
At the end of the day it's all about the money.
Because.... (Score:2)
Honestly I do not log into most websites, so why should they "encrypt it"?
if you are not logging in, then who cares if it's encrypted.
Also I have seen very good login systems that are encrypted from client to server that use a JS client side encryption system and it does not use cookies to keep you logged in. Unfortunately most web developers are lazy and dont do a nice secure non https login and session system. https is the fix for lazy cookie session status.
Name-based virtual hosts and TLS/SSL (Score:2)
Most web sites run on name-based virtual hosts. This allows multiple web sites to use the same instance of the web server (Apache, IIS, etc.), reducing costs.
This presents a chicken-an-egg problem with TLS/SSL (the encryption used for https).
When the web server receives the initial request from the browser, it sends back a certificate for it's domain that says to the browser, "Yes, I am really where-ever.com, because I paid money to GoDaddy, Comodo, Verisign or whoever and they'll corroborate."
The problem i
Does this even merit a reply? (Score:2)
Okay, let's look at this one issue at a time:
1. The great majority of small sites (which an earlier poster has said "wouldn't notice the extra load") run on shared servers. The hosting company certainly would notice the extra load, they'd need more servers, therefore more electricity and floorspace, therefore higher costs, therefore hosting price goes up. Probably rather substantially.
2. HTTPS requires 1 IP address for every site you host. (There is the SNI extension but if this article [techrepublic.com] is to be believ
The security advantage may not last long anyway (Score:3)
If HTTPS becomes ubiquitous, then there will be much more opportunity, as well as more incentive, to break the encryption consistently and therefore nullify the security.
On the other hand, if everything is encrypted, the traffic that truly NEEDS encryption will be less likely to call attention to itself, because the 'needle' will be in a bigger 'haystack'.
All in all I think it'll end up being a wash.
Re: (Score:3)
If SSL (really TLS as SSL 3.0 is really becoming a dead protocol) can be broken, you must assume it already has been and that the only safe strategy is to get it broken in public so that it can be fixed. In other words, you want ubiquitous encryption and you want it as heavily tested as possible.
(This reminds me of a story. Apparently, Rolls Royce were not impressed with the reliability of their Merlin engine, so they'd take one at random, ramp it up to full power and leave it until something burned out or
everything has a cost (Score:3)
Forget about the computation on the server to encrypt everything, and about the computation on the client to decrypt everything. HTTPS requires three connections where HTTP requires only one.
In short, because you need to have a signate ring, a sculptist, and a wax candle, in order to seal the envelope. LIcking glue is faster and cheaper.
People forget what security is really about. It's about stopping people that you actually can stop from doing something that they're actually trying to do. It's not about stopping Ethan Hawk from opening your e-mail, and it's not about stopping an infant from stealing your car.
Chances are that no one is actually trying to break into your twitter account. Unless someone is, or you suspect someone is, there's nothing to secure.
By the way, it's safer to walk around with a body-guard. Have you hired one?
Because its more processor intensive (Score:3)
...slows down browsing, and who gives a crap, for most sites it doesn't matter anyway.
Re:Holy fuck! (Score:5, Informative)
Facebook and twitter don't have secure logins?!
That's one more reason for me to never sign up with them.
They have secure logins, just not secure sessions after you've logged in.
Re: (Score:2)
I just always visit https://www.facebook.com [facebook.com]. Seems to work. There is also a setting I noticed that says something like "use secure sessions wherever possible", which perhaps redirects you to the https site even if you click on an http link. I haven't tested it though, I'm happy using https all the time so that people can't steal my session cookie or whatever.
Re: (Score:3)
Dunno about Twitter, I'll never use the site. But Facebook does support full HTTPS connections, and there's an option in your profile to force Facebook to use https on every connection on your account.
Re: (Score:3)
Facebook fairly recently added an option to always use https.
Twitter announced a few days ago that it was adding the same option. No idea if they've implemented it or just announced it though.
Re: (Score:2)
Facebook has full https control (they had partial, but some APIs didn't work, they do now) and Twitter works with https as well.
Using https seems to be becoming default, rather than an option, and yes, it does requires more muscular hardware and yes, it uses up session sockets. Ultimately, it's what we'll use until it too, gets cracked.
Re: (Score:3)
chat was disabled
Sigh... I considered that a feature.
Re: (Score:2)
Actually the first part is readily solved by the use of "subject alternative names".
This is a problem price wise, since crooks like verisign insist that you need some special package to request such certs, and then each name is the full price of a full cert per year. so no break at all on cost (though, you could not use verisign)
I would love to see CACert in the default CA databases widely, that would help a lot.
Re: (Score:2)
Not every web-site needs you to log in. I know it sounds shocking, but for some of us old-timers who remember the web free, that is how it is supposed to be: you publish your information to be accessible by everyone.
Without user authentication, how do you prevent a vandal from removing what you have published in favor of what he wants to publish?
Re: (Score:2)
[blockquote]I would have hard a time recommending to anyone to run their whole site in SSL. Get the logins or most forms in SSL, but the rest would be overkill.[/blockquote]
While most of your post is correct, not that part. Encrypting the login without encrypting the rest of the session is virtually completely pointless, since you leave your users vulnerable to session replay attacks. Yay, I don't know your password! Who cares, I have your authentication token.