Slashdot Mirror
Why Doesn't Every Website Use HTTPS?
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?"
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.
Facebook and twitter don't have secure logins?!
That's one more reason for me to never sign up with them.
Technoli
Maybe because it requires certificates that cost money and annoy users when they expire?
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)
For the company I work for it's because Certs cost money, and self-signed certs are a pain for users.
Because trusted certificates are expensive and don't last long?
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. :)
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)
....every [sub]domain needs a dedicated IP for the certs to work properly.
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. With that in mind you do not publish pictures of yourself or your friend hugging the johnny.
It cost CPU to crypt and uncrypt! Some servers are dedicated to this task (it s called ssl off-loading). But why do you want HTTPS everywhere? look at the CA you have in your browser. You may have a tunisian or a chinese certificat which means that thay MAY intercept your traffic and read it clearly :)
The answers to this question are so obvious I wonder why the question was posted to begin with.
1. Additional processing power and bandwidth required to encrypt/decrypt secure streams.
2. SSL certificates can be expensive in some cases.
3. It's just one more thing that can expire and whose lifetime must be tracked on a production Web site.
I use to work for.... big hosting company. We were constantly getting calls about problems with https, especially people who bought their https from another company. Most of the problems were people not filling out the information correctly causing the https not to resolve or the other company not communicating with us properly. It's also just another thing to remember to renew every year.
my karma will be here long after I'm gone
If you're posting personal info on Facebook or twitter then you're already an idiot. Posting your personal info by https isn't going to make you less of an idiot.
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.
"When information is power, privacy is freedom" - Jah-Wren Ryel
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.
For your security, this post has been encrypted with ROT-13, twice.
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.
I am officially gone from
Part of this was discussed long ago, 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.
You can't handle the truth.
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 understand that you need a certificate chain for banks and things like that... Fine. Let them pay money for that. But at least give us the option of having self-signed certs that function. No, it's not as secure as a certificate chain, but it is better than plain-text.
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
Blessed are the pessimists, for they have made backups.
There is no reliable method with https for determining what website is being requested before the user accesses the website. If for example (just making it up, fortunately it wouldn't happen) Facebook and Google were hosted on the same IP addresses, other then differentiating by port, how would the servers be able to tell what website is being requested? They could send Facebooks certificate for google requests, which would cause alarm for the users because wrong site certificate issues. Coupled with the price of certificates, its not a viable option at this time. However, if we made a way to differentiate between websties before we send the cirtificate, then https on every website in the world would be a viable option.
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.
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?
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.
Please read my Canon EOS tech blog at http://www.everyothershot.com
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 to slow connection/ battery taxing considerations of having HTTPS on all of the time that desktops aren't subject to
but, back to desktop, here's a corollary question: why isn't everyone on ipv6? all sorts of new abilities come into possibility and all sorts of problems are solved with such a huge address space
but here's the rub: all of the benefits are modest enough that it doesn't necessarily outweigh all of the costs involved in making the transition. and the same answer applies to using HTTPS all of the time
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
1) Granny's not going to pay $100s per year for her blog.
2) Processing overhead. Security comes at the cost of speed.
HTTPS also requires a dedicated public IP, so you can't share your IP with other websites. Many cheap hosting environments have many websites running on the same IP. This is no excuse for people like Facebook, Twitter, or other big names, but this is one reason why *all* websites don't use HTTPS. For the most part, a cert can only be used for one website. Shared IP hosting uses the host header in the HTTP 1.1 protocol to determine which website to deliver when it receives a request on an IP that hosts multiple websites. The problem with HTTPS is it encrypts the host header, so the web server doesn't know which website to deliver. It can't decrypt the traffic until it knows which cert to use, which it could determine using the host header (which it can't get until it decrypts the traffic.) Chicken and egg scenario...
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.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
At the end of the day it's all about the money.
Two of my imaginary friends reproduced once
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.
Do not look at laser with remaining good eye.
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 is, when that first request comes in, and you are using TLS/SSL and name-based virtual hosting, the server can't read what domain name was requested to present the correct certificate. You haven't finished negotiating the TLS/SSL connection yet, so you can't read the URI embedded in the request.
So, you need a different IP for each domain that you are going to serve (IP addresses are becoming rare) or use some other hack to accomplish this.
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 is to be believed, it's not supported under IE on Windows XP, or for that matter Safari on any version of OS X prior to 10.5.6 - which means it's really not much of a solution yet).
3. Cost and Complication. Sure, hosting providers could bake into their control panel a process to generate a CSR, get it signed by a trusted CA and install the signed certificate without all the messing around this normally entails, but virtually every reputable CA that already has their root certificate in widespread use charges for signing. Oh look, more cost.
Cost & Complexity:
- certificates aren't free
- certificates need to be properly managed
- encryption requires computational power
- you would be surprised how many things break when you move around http:/// to https:/// in URLs. There's a lot of amateurs implementing things.
- a SSL cert is usually married to a dedicated IP address, this makes it cost or technically prohibitive for web hosting companies. IPv6 won't be around for a while.
and more importantly
- SSL is not necessary all the time!!!!
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.
Wearing pants should always be optional.
They do use HTTPS for login authentication, and your username / password are sent encrypted. The authentication token is transmitted unencrypted on those sites.
There are reportedly free certificates through StartCom, but how does the server know which certificate to present to the client? The HTTP Host: header doesn't show up until after the connection has already been established. There is SNI, but a lot of deployed clients still don't support SNI; they need a distinct IPv4 address and port per server. End users expect all hosts to run on port 443, and we've run out of IPv4 addresses.
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.
'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
Cost.
financial transactions are ALWAYS handled by 3rd party usury security forces. most of us have no (0) secrets.
Certificates form TTP's aren't free.
Never say never. Ah!! I did it again!
The poster has changed
[Every time you log in to any service that uses a plain HTTP connection that's essentially what you're doing.] to
>>Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection and that is not accurate. The Facebook login page uses https.
No
1. Name based virtual hosting doesn't work with HTTPS (unless all virtual hosts use the same cert)
2. Requires more CPU grunt on the web servers
3. Certificates cost money
4. Certificates expire and hence add work to keep the site up and running
5. Embedding http resources in an https page cause some browsers to pop up annoying confirmation boxes
...most content on the web need not be secured.
The CPU overhead of SSL is largely moot at this point; except for servers handling millions of requests per hour, any server from the last 5 years or so is powerful enough that SSL overhead is lost in the noise. I manage a server that gets over two million requests per day (mostly during business hours), all of them SSL (but almost all for static content), and the server is 97% idle during the busiest periods. There are two major reasons people don't use SSL.
First, SSL requires each site to have a unique IP address; shared hosting with multiple sites per IP doesn't work. There is an extension in TLS (version 1.2 IIRC) that allows for multiple sites per IP, but browser support is spotty. IPv6 will fix this (since it'll be just as easy to put sites on different addresses and the same), but not for many years (after IPv6 surpasses IPv4 in market penetration).
Second, SSL requires more maintenance and costs more. The site (or server) admin has to manage the SSL certificate and get it signed periodically (every year or two in most cases) by a recognized certifying authority (CA). Somebody has to remember to do it (or users get warnings) and it costs money (the cheapest widely-recognized CA I'm aware of is $50/year).
People here like to rail against the CA "cartel", but SSL without CAs is mostly pointless. If non-SSL is like a postcard, SSL without CAs is like putting your username/password in an envelope and then flagging down the first person you see and asking them to deliver it for you. Without CAs, you don't know who is on the other end of the encryption path; you could be the subject of a man-in-the-middle attack, a spoofed domain, etc. Some of this can be mitigated by just accepting a cert the first time you visit a site (and verifying it is the same on future visits), but that doesn't protect you against MitM on the first visit or when the cert expires and is replaced.
I noticed a lot of comments mentioning extra processing, but also browsers don't cache any SSL transferred content between sessions. This includes things like stylesheets, images/sprites, scripts, etc. This can give a poor visitor experience.
It's probably a bad idea, but I think if browsers didn't give a warning about loading "unsecured" content (like any of the above) over a "secured" connection this would be less of a problem. It would be handy if designers were able to say that a particular piece of content is cacheable even over a secured connection. This would provide a better experience.
Although less of a concern now, (transparent?) caching HTTP proxies cannot help speed up the web over HTTPS either.
Filtering HTTP proxies are more common, and are rendered ineffective by HTTPS.
Why doesn't every house have a digital+analog lock with one time pad? And why doesn't my car fly?
It's called cost and effort smarty pants. It's not like we've been over here in the dark ignoring it.
Tiger Blooded Bi-Winning Machine
Because it's impossible/complicated to have multiple "HTTPS'd" domains on a single IP address.
Also, it's not really more "secure" in most senses of this word.
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?!?
This is called the "key continuity management" model, and web browsers support it as well. Firefox 1. warns that banks don't use self-signed certs, 2. presents the cert to the user so that the user can look at the fingerprint and compare it to a fingerprint exchanged out of band, and 3. allows the user to whitelist the fingerprint. The trouble with the is that if you're MITM'd the first time you visit the site, you're screwed. There is an alternative approach known as Perspectives that uses notaries distributed throughout the Internet to find MITMs, under the assumption that a single MITM will be able to compromise only a small number of paths through the Internet, but it doesn't really work for a MITM between the server and the backbone. In addition, I haven't seen the Perspectives add-on ported to Firefox 4, to IE, or to handheld browsers.
"...Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection..."
Uh, we're worried about the password getting leaked for those on Twitter or FB who are sharing their entire lives for 564,472 "friends of friends of friends" to see anyway?
Sorry, I do see the point here with HTTPS, but damn, you couldn't have provided a worse example of sites with "privacy" concerns. People don't give a shit anymore about privacy, they're more concerned about being plugged in to the rest of the sheeple network.
The only time people are concerned about security online is when it comes to their banking institutions. The irony here is the ability to get a decent job in the future and feed that bank account is directly correlated to the self-control to NOT post that drunk/half-naked picture at last weeks frat party on social networking sites. Fat chance of that happening.
- 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.
You can pick up a single site SSL certificate for under $20
And a dedicated IPv4 address for $60, according to Go Daddy. Otherwise, you shut out users of Android 2.x and users of Windows XP, whose built-in SSL library does not support SNI.
yup. looks like the most 'successful' vandalisms etc..., come from having a root/admin/? in your pocket/phone/'family' of mindless bots. never mind the sintax or holycost, it's just bad manners at best?
Here's my list of all the sites that I can think of that use HTTPS and only HTTPS:
1. Paypal
2. Launchpad.net
I honour both of you. Not even my bank made it to this list.
...because browsers don't support SSL-enabled virtualhosting yet?
I wonder if there is a middle ground. It would be possible on Javascript enabled browsers to calculate a hash (MD5, SHA or similar) using the password plus a seed and send that to the server instead of the plain text password.
Server Name Indication [...] is still not universally available and thus it will still take some time
In this case, "some time" is until April 2014, the announced end of extended support for Windows XP, or two years after Android "Ice Cream" phones start shipping, whichever is later. Neither IE on Windows XP nor the browser on Android 2.x supports SNI.
I'm no web developer but one issue that we had: you can't redirect based on the URL.
Example: On our webserver we were serving multiple pages off of the same server, and depending on the URL entered the server would serve up different pages. IE, both www.boatsite.com and www.hikingsite.com resolved to the same server IP address, but the server would present a boating or hiking site, respectively, depending on which URL was entered.
HTTPS broke that because we weren't able to read the URL until later in the process when it was decrypted.
Like I said, it may have been an IIS limitation or just a knowledge issue of our webmaster (which isn't me - I was just tangentially involved in this issue), but this did present a bit of a headache.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
If you're running some blog or forum on some piece of php coded crap-ware that would get hacked in about 5 minutes by anyone who cared enough to bother trying to snoop http traffic, why bother running SSL?
Because it's morally wrong to support the SSL industry. There are some good guys out there, but most are just out to charge you for not doing any work. Meanwhile every corrupt regime and shady organization has their own root certificate in your browser, making the use of SSL against *real* threats virtually non-existent.
E.g., for my Hong Kong company I can't get an EV certificate unless my company appears in a certain business directory. Essentially they are outsourcing the verification of my business to this directory (which is very expensive), yet still insist on charging me a ridiculous amount of money. Yearly.
A real cert cost an arm and a leg. Twitter, etc can afford it but your average little low-traffic site probably can't. I run a couple domains and know I can't.
I assume that the real problem is IE6, because it doesn't support SAN in certs. Absent IE6, all modern browsers should support this 8-year old technology which handily bypasses the issue you are describing.
SNI, probably a better overall solution, doesn't work with Windows XP at all, or older versions of iPhone OS. Once the older platforms die, it's the solution that we should move to.
Because some idiot set up a system where it requires hundreds or thousands of dollars if you don't want the user to get a warning upon visiting your SSL site.
Verislime still ultimately "runs" PKI.
so that's good? because it's the same co.gov that helps to armour our Internet & protect us from same as needed.
Recent versions [of Internet Explorer] certainly support [SNI]. Perhaps IE6 does not, however many sites have already stopped supporting it at the design level.
IE 9 supports it. IE 7 and 8 support it only when run on Windows Vista or Windows 7, but then those operating systems come with a free upgrade to IE 9. So a useful approximation is that IE 8 and earlier probably don't support it.
Both apache and modern browsers support [SNI] just fine.
A large percentage of your users are likely to be using a nonmodern browser. This includes Android 2.x and IE on XP.
Actually, IDS is the main reason my organization doesn't use HTTPS. (and then the bandwidth lost from losing the ability to specify caching)
With HTTP, the IDS is handled at the firewall ... with HTTPS, we'd have to do something per machine. Apache's mod_security might be enough, but we'd have to deal with the security department more often; I don't know if they'd want to audit our logs, or if they'd trust us to do it. ... it's just easier to let them do their scanning and leave us alone ... well, up until they detect someone probed us, and shut us down, and make us jump through hoops to get the machines allowed back online again.
(and you seem to be the only one of ~150 people so far who actually mentioned a downside of SSL other than cert cost, caching/bandwidth issues, ip allocation or cpu cost)
Build it, and they will come^Hplain.
It seems that the biggest beef is expensive certs. Can we not do without host-authentication ? Encryption as such doesn't require it. You send me a public key, I send you one, we agree on a session key, done. Doesn't matter if the host isn't who he says he is - let's say that there are other (more personally bound) ways to ascertain that - or maybe given the context it really doesn't matter. Only protection from eavesdropping.
Religion is what happens when nature strikes and groupthink goes wrong.
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.
No sig today...
Security is an afterthought, and HTTPS is not the default, and people don't get around to fixing that. In any case, web application security as we know it is a horrible, scary kludge. The only reason it's not a scandal is that we're *used* to this sorry state of affairs.
It's not just applications that make security an afterthought, frameworks, platforms and standards like TCP/IP have security bolted on after the fact. TLS is only one example. It patches two important security concerns, eavesdropping on network transmissions and (only if you get a certificate from a trusted CA) man in the middle. Client side authentication in TLS goes a lot further, but we're still subject to many exploits of the server's trust in the browser, or the browser's trust of executable content delivered by the server, even when one would not expect that.
I've been studying Web application security and Web Services security recently, and it occurred to me to ask: why has so much effort gone into building so many kinds of services and apps on top of a protocol that was designed for delivering static documents? Obviously because that was easier than building new protocols, but why is it easier to hack HTTP to do what we want instead of purpose-building new protocols? It's a bit like cut-and-paste coding.
I think the answer is that the standard TCP/IP protocol stack is missing something between the connection layer (TCP/IP) and the application layer (HTTP), a layer that provides a common set of services such as negotiating data encoding, managing objects and resources needed in a session, common messages to handle configuration or authorization problems, handling state updates between client-side objects and server resources, etc. We'd still need HTTP to handle the scalable distribution of static content of course. Rather than factoring out all the functionality we've kludged onto HTTP to create a new protocol or intermediate architectural layer, it's far quicker to use those facilities as-is, and since *everyone* does things this half-assed way, nobody gets blamed.
This is the lava flow anti-pattern on such a grand scale we can't *see* it because the entire field is *embedded* in it. The worst result of this is the automatic bias toward not just delivering, but running actually apps in the browser. The shared state and trust granted to the browser by the server is a key avenue of attack. The excessive power of HTML with embedded scripting for many applications is another. That's simply not the way you'd architect a system right from the start to deliver secure applications to thin clients. It's how you'd hack application delivery onto a document viewing infrastructure. That's an obviously stupid way to do things, but people were in a hurry and now we've accepted its shortcomings as the way things are and have to be.
If I had to architect the delivery of applications to thin clients, I'd make it possible to build and deploy user interfaces and interfaces through something like XUL or Flash, and have a generic data interchange and session management protocol that delivered strictly typed, non-executable content to and from the client. The application itself would be signed so no unforseen code ever gets executed. Each application would run in a different memory space and credentials and authorizations would be inaccessible from outside the app. If we did things that way, right off the bat a low-level code monkey would generate apps comparable in security to what the best web app designers can accomplish today, because the best practices would be factored out of the good designs and made the path of least resistance for the less capable designers.
That would be common sense, but it's not going t happen. Instead we'll get more demands for creating rich but kludgy and insecure Internet apps because of inertia.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Why are all of those shitty things true, inquiring minds would like to know. And what about the five whys?
Why do you need a cert to establish privacy (protect against eavesdropping)? Why can't the (one way) authenticity exchange take place *after* basic security is established.
Why is there no mode with encryption, but without the bother of an SSL certificate at all?
Why was it ever possible to send a password in clear text to begin with?
Australopithecus protocol designers, you have a lot of 'splain to do.
You can't trust the network and you can't trust the companies running the network. Eventually, against the explicit wishes of every marketing team out there, we're going to end up using SSL on everything. If it's SSL none of it can be sniffed or inspected (at least not without significant resources). ISPs can no longer sniff your google search terms or hostname requests. They can't sniff page content. And if they can't do any of that they can't try to target you with advertisements.
Encryption even (kinda) solves the net neutrality issue. If ISPs can't inspect the packet to see what's in it they can't prioritize it based on whether or not it's paid prioritization.
I'd encrypt everything right now if I could...but it takes two to play that game and it's going to take a while for everyone to be dragged in that direction.
i would force all 2,400 websites my company runs for other companies to all use SSL, apart from the cost of an SSL certificate from pretty much anyone who sells them.
i could create self signed certificates, but then that would require a change in the skitishness of browsers that seem to thing just because i signed the certificate myself, its some how not secure enough and flash up a massive warning to viewers of the website.
so, either we need vastly reduced prices for SSL certs, or we need browsers to be less picky
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 verified that the site you are connecting to is genuine (translation: you have crossed your fingers and decided that your piss-ant little site is not interesting to the black hats) - but the browser can't know that you've done that. The only responsible thing the browser can do is warn you that (as far as it is concerned) the connection could still be insecure before displaying the "secure connection" symbol.
If you're using self-signed certificates then you need to be in close enough touch with your users to reassure them about the browser warnings. If you have too many users for that to be practical then you shouldn't be using self-signed certificates. Otherwise, you're acting like my bank, who cold call me and then wonder why I won't answer their security questions - they know they're genuine, but they can't get it into their heads that the customer doesn't know, and shouldn't assume, that.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
Computers now can handle a lot more load.
They can on a query-by-query basis. What's an extra millisecond?
Assuming SSL needs twice the power as http, you'll need twice as many servers to support https over http. If your site is large enough to be spread over 2+1 boxes, you'll need to increase to at least 3+1.
Site certificates cost too much damn money and are too damn restrictive. I can't buy a certificate that will cover every conceivable iteration of my domain name unless buy an "unlimited subdomain" cert which is usually 2-3x more expensive than a single domain cert. And GOD HAVE MERCY ON YOUR SOUL if you actually have more than one domain name pointing to the same server...
Obviously you could just turn on https and redirect all traffic to it with a self-signed certificate, but when you do that every browser that visits your site starts screaming OH MY GOD I DON'T KNOW WHO SIGNED THIS EVIL HAXXX0R5 MIGHT BE STEALING YOUR IDENTITY AND SIPHONING YOUR BANK ACCOUNT AS WE SPEAK. This tends to degrade your average visitors confidence in the authenticity of your site.
I'm speaking from experience, since I had to go through this crap last October when Firesheep came out.
The good news is that 99.9% of all blogspam doesn't know how to handle https. Yet.
Eviscerati.Org: All Hail the Eviscerati
SSL is flawed from the start. As an Admin I often has sites I want encrypted for privacy. I do not collect credit card information, I do not sell shit. The fact that SSL is tied to a certification of validity is absurd. These signing authorities act as a notary public that validates you are whom you claim to be. In the past I have even had to fax over a copy of my business license to obtain one. This works well if I want people to know I am not a fraud and am collecting credit card information. However, there's many places where I want to SSL for encryption alone such as web based email, the admin interfaces to phone systems, the admin interface of firewalls etc. Someone like us has no problem clicking past the obnoxious warnngs about untrusted SSL. Your average user isn't. As stupid as they are about downloading virus, trojans, fake antivirus' and malware, these same people wont go to a website that IE turns bright red and warns about sudden death over.
it really needs to be two mechanisms...
encryption should be a separate piece. Good encryption should be independent of authorized validation. There should be two checks, one for good encryption and then further check for valid trusted signatures. Dont show the secure lock on encryption-only links, display a different icon to indicate encrytion only. If these signing authorities could lobby their way they'd have you paying them anywhere from $35 - $350 every time you wanted to turn up a website. Thats worse than a tax and what makes them so much 'in the know' on who is who anyway?
Have you read their terms of service? They want you give them your RESIDENCE address even if you're getting the certs for a business. Sorry, I haven't the slightest idea or interest in why they'd want such information. Business address, sure. Residence address is none of their business and that they're even asking for it tells me that they're clueless and/or evil. Even my employer doesn't know my residence address (I get all business mail including work-related stuff at another address).
I do ok with startssl.com certificates at $15 a year through resellers.
I reuse a single user name and password for all sites which do not require personal information of me or manage my financial or medical data. This means, if they do not ask my mailing or billing address, ssn or license number, financial or medical records, I have one user name and password I use on all those sites.
Loss of use for the sites in question are meaningless to me. If someone stole my user name (whether site operator or not) I would incur no losses. They would first have to know what other sites I frequent but since I have nothing invested in those sites I have nothing to lose. Yes, Slashdot falls under that category to me.
I do maintain separate passwords for any site which I access which has my address and or financial information. Most of those sites don't have user names and require real e-mail addresses so I treat them with the importance they deserve.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
Part of the problem here is that everyone thinks using HTTPS will make you safe. Sure, it will make your browsing more private, but that's not the same thing.
Let's not forget that whether you're using HTTPS or not, malicious or compromised sites can result in an attack through your browser. One your company safety methods cannot detect.
At least one company just started dealing with this by blocking all secure web traffic. A company whose security division was recently hacked. An organization very few people ever though *could* be hacked, seeing as their name is synonymous with the secure handshake (literally).
'nuff said?
>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.
No you don't understand HTTP/HTTPS.
Form loads over http. However the action of the form is https.
Here are the form tags:
Facebook - form method="POST" action="https://www.facebook.com/login.php?login_attempt=1" id="login_form" onsubmit="return Event.__inlineSubmit(this,event)"
Twitter - form method="post" id="signin" action="https://twitter.com/sessions"
During an https transaction, the secure socket is established before the name resolution happens, long before the form data is sent. Even so, some proxies (such as MSProxy) will log data sent over GET, so as long as the action is an https URL, and method is POST, you are good, provided the certificate is valid.
Here are the steps starting with form load on either of these sites:
1. form loads in your browser
2. you fill it out
3. you click submit
4. in the case of facebook and twitter, a secure sockets connection is initiated to the URL in the action tag of form. This happens after name resolution, but occurs directly with IP of site. This will happen with any https form POST URL.
5. page request headers are sent (including your form data) which include the domain name of the site (host request header)
6. facebook or twitter puts a cookie on your computer with a session id
7. you get bounced back to http
There is nothing insecure about this. I'm the last guy to say that facebook and twitter are secure, and this is due to how information is shared, but their login forms are perfectly fine.
Suggest you learn how http and https work before starting a sensationalist story like this about HTTP security (or lack thereof) ;-)
I can't believe all these slashdot posts of people that bought into this story before bothering to check the login forms for themselves.
Now go learn how HTTP works before writing stories about it.
Don't kid yourself. It's the size of the regexp AND how you use it that counts.
The answer is very simple: 1) Every SSL-enabled website must have a unique IP address, which makes it impractical for shared hosting environments where hundreds, or even thousands, of websites share an IP address. There aren't enough IP addresses available to make this feasible. 2) SSL isn't free. You have the cost of the certificate, which is usually $50-100. Then you have the additional CPU cost. SSL requires the server to encrypt every page request, which adds considerable CPU overhead for busy sites, or for servers that handle multiple sites. You can offload the encryption to an SSL appliance, but these also cost money in terms of initial capital outlay, and recurring management expense. 3) Encrypting websites that contain no sensitive information is a waste of resources and is a bad practice IMO. It makes things infinitely more difficult to debug since you can't see any of the data as it crosses the wire, which makes it difficult to trace network-related problems. 4) You can't cache encrypted content, so it would add significant overhead in terms of additional bandwidth. Network operators will not appreciate this. 5) The additional cost and manpower from all of the above make SSL by default impractical. Too much cost and complexity with not enough incentive. The current model works well enough. SSL is dirt cheap on an individual basis. If someone runs a site that contains sensitive info and they want to secure it, there is a very low barrier to SSL adoption in terms of cost and complexity, which is good. Maybe not so low that everyone will run out and buy SSL certs for their blog, but every company with a public facing webmail site or extranet should definitely have SSL.
The fundamental problem for me is that https is a hassle and costs money to implement. You have to buy the cert or at least go through the rigmarole of obtaining one, often accompanied by submitting scans of government documents or whatnot. At the end of this process you get a time limited cert which has largely meaningless "trust" attached to it. For medium / small businesses and end users all this hassle is a major obstacle.
The kicker is this issue has already been resolved - webs of trust. PGP lets users roll their own key, distribute it to people they know who subsequently sign it. As people sign each other's keys they build up a trust model uniquely amongst themselves.
It's too bad Google, MS, Firefox can't work together on an extension for self generated certs which are then signed by a PGP key instead of a CA. Instead of trusting the CA, the user trusts (or distrusts) based on the web of trust. The cert never expires but becomes invalid if the PGP key is revoked / expired. Then anyone can roll their own cert without the inconvenience and expense of buying one.
At the point that certs become freely available, the use of https would sky rocket. At the very least people would benefit from encrypted communication, and where trust is required they'd have that too and probably more of it than some worthless CA sig,
A better question is why isn't the entire Internet just using ipsec and encrypting _everything_ instead of re-inventing this wheel one application at a time?
that's why I wrote a security framework that runs over HTTP and Ajax but is, as far as I can tell with my testing so far, as secure as HTTPS... with no need for expensive certs... It doesn't give you the nice blue / green address bar or the lock icon, but it's very secure when used properly. Decided not to go the patent route with this project, with all the changes and uncertainty in the patent landscape here in the US... but I would still like to get something out of all of my work and effort... so... I'm willing to give it to a few small companies for free as beta testers (with some consulting services) if they want to do an NDA... also, if there are any security experts out there who want a look-see... just send me an email... NDA there too... I'm going the trade-secret and copyright route on this, but hopefully it'll pay off. Anyone interested, let me know... (check email address on my profile)
Logic is the beginning of reason, not the end of it.
Sending your password in the clear even if it is over an encrypted SSL channel is not such a great idea either.
All we need are for browsers to support TLS-SRP for authentication and then we get secure authentication for free... (**without** paying for SSL certificates)
A number of new processors today have native AES instructions in hardware and IPv6 deployment or https upgrade via http will make it somewhat easier for hosted sites to switch.
There is also an opportunity for DNSSec bindings.
Assuming the limitations discussed were overcome and all servers provided https pages, wouldnt the bad guys just switch to attacking https? There are already tools that provide a man in the middle method of decrypting https session traffic - though these generate a fake certificate which will pop up a warning on the users browser (which most users will just accept). Or you need the servers private key which with current technology it is not feasible to discover (but at some point it may be)
The original article gives several reasons for why HTTPS isn't ubiquitous: cost of certificates, cpu cost of encryption, HTTPS can't be cached via web proxies. I've always thought that there was an obvious solution to all three of these. Don't run HTTP through a secure tunnel (TLS). Instead use HTTP to retrieve signed objects from the web server. Think of it as HTTP retrieving PGP signed objects. Yes, you lose some of the privacy aspects of using HTTPS, but you can still verify that the objects you received have not been modified. In a mixed environment where both HTTPS and HTTP/PGP are used, things like logos, standard javascript code, and all manner of stuff that really is static could be retrieved with HTTP/PGP while personal info or truly dynamic data would be retrieved with HTTPS. Sites that don't have personalized data would rarely if ever need to use HTTPS at all while substantially improving their security model.
I admit that there are all kinds of details involved with getting this right (man in the middle replay attacks, key distribution, etc.), but I'm convinced that they could all be worked out. Internally versioned objects, retrieve keys via HTTPS are two possibilities for those specific problems. Virtual sites with "static" content could share a single HTTPS enabled site for the purposes of retrieving their "PGP" keys. The actual server software wouldn't have to change. Content creation/management would have to add signing to the process. Browsers would need more extensive modifications to change their security model as well as implement the required PGP-like functionality. Working with HTTP proxy caches while still defending against man in the middle attacks might require using HTTPS to get version info while using HTTP/PGP to get the objects themselves. "Static" sites could keep the current site version info on the same shared HTTPS enabled site where they keep their "PGP" keys. Options for per object/per sub tree/per site version numbers in the standard would allow maximum flexibility in content managment. Something vaguely like robot.txts perhaps?
Please someone go off and work out the rest of the details, write a standard, and implement this in a way that doesn't require proprietary software and at least allows the option of a PGP "web of trust" model of security rather then the commercialized model that HTTPS encourages. Then contact bogstad@pobox.com for info on where to send the beer.
Even though by default your session isn't encrypted when you login the form submits to an https url so it is incorrect to say that you are sending your username and password in the clear.
Plus, if your not doing shopping or authentication, or the authentication isn't really a huge deal such as posting a comment (Where's HTTPS on Slashdot!), why spend the money on the cert, time setting it up, and the extra hardware requirements. That being said, HTTPS should probably be used for all passwords because users may use the same password on a blog as they do for online banking.
A couple of years ago, I saw a comparison of Apache/Red Had vs. IIS/Windows that left a lot of people scratching their heads. The central test of the comparison was a comparison of a couple of hundred clients trying to read the same files from the server at the same time. Anyone that knows networking basics would know that 100 clients trying to create http sessions over tcp/ip would each require the files to be spooled to them one at a time and the maximum through put of the 10baseT network they were using would be 10Mbps / (8 data bits + 1 stop bit) = 1.111MB/s which is exactly what the Red Hat server maintained. The windows server magically transported 100MB/s over the same wires! How could this be?!? My thoughts about this have always been that IIS was not using http over tcp/ip, it was using http over udp. That meant that all 100 clients could be added to a multicast group and receive the files at the same time. This does mean that you could never attain the same throughput over https, though, because each session would be forced to be separated.
Just a quick thought..
Qybix ----- I do not have a belief system; I'm an Anti-theist and proud of it! Saying that not believing in anything i
It works fine with load balancing if the SSL is terminated at the load balancer so the data can be read. i.e. required for cookie persistence... plus all sots of other fun stuff.
Because getting a cert is a pain and an expense. And because you have to spend cycles on the encryption (yes, for a high-volume site, that becomes a consideration).
Not only do browsers scream bloody murder if you attempt to access a site with a self-signed certificate, but they also do so if you access a page with mixed http/https content, making it impossible to do so. This prevents using a CDN to host the static content of your site (which likely has no authentication requirements, anyway) or allowing proxy caches to do their thing with your content if you use full-time https. A simple html extension which would allow the site to indicate that a resource URL can be legitimately re-written by the browser to a non-https url would solve a lot of the problem. Set your session cookie to be https-only but allow the browser to resolve static content from http when referred via an https url (without including the secure-only cookies) and you'd see a LOT more sites using https for all dynamic, user-specific content. The extension would need to allow the use of relative urls and use the insecure attribute to indicate to the browser that it is safe to rewrite to the insecure version of the protocol. I'd switch all of my sites over to full https almost instantly. As it is, I currently do the 'encrypt login and settings pages and require re-auth to do anything important' thing.
HTTPS requires greater administration, especially in multiple server setups where a session may talk to more than one machine during a session, and has higher computational overhead on the server. If you don't use https for every item on a page (to save computation or to use an http only server for content that doesn't need to be secure) the user gets an annoying warning.
Support SETI@home
Wish I had mod points.
Support SETI@home
Without Server Name Identification, every site would have to have it's own IP address. There simply are not enough IP addresses for that (think of that transition being the ultimate un-NATing).
Unfortunately, no version of IE installed on XP supports SNI at all. So, blame Microsoft.
The rest of the world has marched on, but not in any particular hurry considering what IE's market share had been. Now that it's starting to lose, the pace is picking up on SNI implementation. That doesn't necessarily mean it will be used, but it'll get easier to do so if desired.
It is a common misconception that just because a site is using HTTP by default that login credentials are being passed to the server over clear text. Go to the login page of facebook or twitter over HTTP and view the source. Even though the page itself is HTTP, the form post action is HTTPS. So browsing the site, pre and post login are HTTP, but the login action itself is over HTTPS.
There are several problems with SSL that make it really annoying for web developers to widely implement.
1) It doesn't work with virtual hosting - you need to provision an IP address for each site that requires SSL.
2) SSL providers are expecting to deal with the domain owner, not the developer. The domain owner in my experience is generally to ignorant to make the purchase.
3) SSL requires payment to a third party. If I could just generate my own certificates, like I do with SSH keys, I would do it a lot more as this would be hassle free.
4) if I manage a few hundred domain names, do I really want to get an annoying renewal notice almost every day of the year?
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?
The performance overhead of SSL/TLS is an easily solvable problem, that's not really the issue. Modern Intel processors now have AES-NI instructions which can be used to accelerate SSL/TLS traffic with modern OpenSSL, plus there's always crypto-cards.
Cost of maintaining certificates aside, you need a 1-to-1 mapping with IPs. You can load balance SSL connections across a pool of servers, but for each domain under SSL/TLS, you need an unique IP address that reverse to the proper DNS name. You can not host more than 1 of virtual host across SSL on the same IP address, that is the real challenge.
If every site were on SSL, you'd run outa public IPs quicker.
I read a bunch of comments and didn't see this one:
The more important question is: why the f*$# the most popular login sites (fb, yahoo, gmail, etc.) don't use it.
My assumption: because they think we don't care, and it's true, most people don't. But I'd love to at least be given the option - these giants can certainly afford it.
I though this was supposed to be an intelligent community.
Wanna buy a shirt?
https://www.redbubble.com/people/stealthfinger/shop?asc=u
I wonder why? Maybe even the act of looking something up might be considered dangerous.
Make sure everyone's vote counts: Verified Voting
The poster makes it sound like when you log in to Facebook or Twitter that your password is being sent via HTTP. That isn't true. When you go to either site you are using HTTP, but if you look at the login form in the source code, it is submitting your password via HTTPS. Once you have been successfully logged in, they switch you back to HTTP.
HTTPS can negatively impact server performance and bandwidth usage and usually doesn't make a lot of sense to use on social sites where posted content is going to be publicly available anyway.
It's too bloody difficult to setup ! Thats the main reason.
There, that wasn't too hard, was it?
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Webmaster is a very broad term. Remember not every site is run by a single person, in fact most of the big ones have teams of many many people working on them. Depending on their systems map, their software architecture, their browser compatibility requirements and a whole host of other concerns using an SSL cert is not always just a matter of dropping the certificate into apache. It could take months to properly implement without breaking the system and upsetting users, and those months come with costs, developers on the coasts cost a business more that $100/hr (cost assumes all costs associate with a developer not just what you are paying them), so assuming 500 developer hours your already in it for $50,000 and that doesn't include planning and testing. Additional servers could easily run you another $50,000 including the labor to set them up. By the time all is said and done, adding that little s to the end of your http can easily cost a business a quarter of a million dollars. That is why everyone doesn't just use it.
Except, of course, that I'm not claiming any magical knowledge. I'm simply pointing out experience - there's a cost to changing systems. Other examples I thought of was gasoline engine vs electric. Same task, different methods. Or even MS Office vs OpenOffice. The interfaces are different, and there's a learning curve. Basically, the commonality of knowledge between HTTP and HTTPS(HTTP over SSL), is such that it lowers development costs and makes the user experience more uniform. Especially if you're banning HTML while you're at it, which means you really need a different application. Take downloading using a torrent vs just downloading from a site - you have an additional application with it's own interface and configuration. Now, yes, right now it happens to be that it's worth it for many people, but it's still an additional cost(options are sometimes worth it though). If it was integrated into the browser via plugin so it 'looks' like it downloads like normal, that'd be even better. Though I'll also note that I'd prefer if web browsers had better resume functions anyways.
I don't read AC A human right
the author of the article and many commentors do not understand. HTTPS by its very nature of being more secure calls for more overhead. Why do we not all carry a safe around in our back pockets when we know it is easy to be pick-pocketed?
The internet already has a lot of "fluff" floating around which slows it down for the rest of us, do we really want to add HTTPS so I can read my horoscope/Cartoon/news article? That certainly sounds overkill for information we do not care to be "in the clear". Certainly we do not want all of our personal/secure information floating around unsecure but "username and passwords on a postcard " is not even a realistic example. Geez, do we need more scare tactics?
There are literally millions of web sites, like my own, that are based on a shared hosting provider, right?
This means that all the domains on a single server starts out by sharing a single IP address. This works perfectly well for HTTP, since the web server will see which domain the client is trying to communicate with, so it can respond with the proper set of pages.
For HTTPS otoh you need something more:
a) A signed (not self-signed!) SSL cert, which means that you have to hand over a not insignificant amount of cash every year or two, otherwise your server will cause strong warnings on every browser out there.
b) A dedicated IP address, since a standard SSL certificate is bound to a particular address.
Personally I am paying about $6-7 per month in total for 5+ domains hosted with Dreamhost, putting them all on HTTPS would make it maybe 10X more expensive.
The solution to (a) above is to make it much easier to accept self-signed certs in browsers, while (b) will be solved by ipv6.
Terje
"almost all programming can be viewed as an exercise in caching"
File compression. Many ISPs today do file compression on your traffic, and good encryption makes the data effectively incompressible. Not only do ISPs not like encryption for this reason, but they sometimes it encrypted traffic to lower priority making encrypted sessions doubly slow for their users.
I have run a small personal web server from time to time. Typically I have half-a-dozen different domains hosted on a single server. Things like individual domains for my company, my personal projects, and side projects which aren't yet ready for prime time. With HTTP, this is easy, as one can look at the requested URL when serving web pages and handle any request for any domain that is being supported.
HTTPS doesn't support this. The best you can do is have a single 'main' HTTPS domain, and redirections to other encrypted ports for your second-class domains. Its not pretty.
There is a protocol called HTTP+SSL that would allow multi-hosting, but last I checked it was mostly non-supported.
If Microsoft would ever fix this bug more sites would use SSL.
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html
I know a company that has some high-profile clientele. The scheduling system this company uses essentially details when and where a specific client will be at a given time in regards to the service the company provides (private aircraft transportation). Some clients have even gone so far as to ask the company and all personnel to sign NDAs regarding this information.
There was a meeting when this new scheduling system came to pass and all personnel were given a UID and told to select a suitably obfuscated password (i.e., numbers, punctuation, upper-case, and lower) of a minimum length of N characters.
During the meeting, one person logged in and noticed that the URL had only HTTP and this person expected HTTPS. Asking the President of the business unit holding the meeting, this person wondered “why no SSL?”. Response, “What's that?” An extremely brief description of what is SSL and why it's handy followed. Response, “Our system's secure.”
Not in the mood to argue with a superior about their lack of understanding of technology, this person went home and fired up Wireshark and Ettercap just to see how ugly it really was. A simple MITM attack on a wireless router showed that company personnel might as well not even bother with an obfuscated login procedure. Anyone suitably skilled and motivated, or just curious, could easily intercept login details and have access to the system.
Further pressing of the issue with the vendor of this scheduling application has only revealed that it's “not their problem” and to take it up with the PHB.
I've seen a few people here say something about how when secure web-sites become the norm, more people will break the encryption, so it doesn't make any sense to encrypt. That's a pretty silly argument against secure web-sites. If a specialist wants to get into my house, I'm going to have a hard time stopping them; but it doesn't stop me from putting a lock on my front door. Also, an open door might be construed as an open invitation to enter, whereas a locked door cannot be. If someone enters my house without my consent, I want evidence that they defeated my security. Also, most physical security (safes and vaults to name two examples) is rated in time. You never buy an impenetrable vault, you buy a vault that would take two hours to breach with the best, currently-available tools. Digital security should be viewed the same way, and it should be augmented with other features such as Intrusion Detection, and Intrusion Prevention countermeasures. As a greater number of web-sites are compelled to become more secure (HIPAA and SOX compliance), point-to-point encryption will be just one of the many required tools in the data owner's/manager's toolkit.
Having said that, it makes sense for all business to secure their web-sites if they are requiring users to create accounts (because sometimes people are still foolish enough to use the same or similar password in different locations), share private information, or make purchases using financial information such as credit cards or Pay Pal accounts. Of course, there should be a reasonable, well-known scale defining how much and what type of security is required based on the type of information stored. This should be audited regularly by the business ("has the information we are storing changed enough to change our security?" and "are we secure enough based on the data we are currently storing?") in addition to regular external audits to ensure that the minimum requirements are met.
All of this, of course, introduces cost into the equation. A small business might not be able to afford a systems administrator to watch the logs, or even to be able to pay for the annual certificate fee, not to mention the dedicated static IP address required for proper certificate usage. This means that larger businesses (banks, insurance companies, large corporations, the military and government) will always have better security than your average smaller business. This means that you, the information originator, need to be conscious of where you share your information, and what you are sharing.
I think certificates should be free, or at least reasonably priced - free would be best - and that security not be tied to IP addresses, which are pretty limited in the IPv4 world.
So, yes, even though a lock won't keep out every intruder, it will keep out the majority of prying eyes. As information security needs continue to improve, so will the associated algorithms used to keep things moderately secure.
Of course, as important as it is to secure the line/connection itself, one should also be very concerned about the authenticity of the person connecting, in addition to the site being connected to. How do you know that you aren't being DNS poisoned or some other man-in-the-middle attack? Is this really your bank? Your insurance company? Your favorite on-line merchant? How do you know? Is the strength of the encryption algorithm really important if you're actually connecting to a thief masquerading as the desired site, intent on stealing your information?
So both of these key factors need to be made affordable (cheap or free), and available to all, not just large businesses with deep pockets and a Class C to throw around. That's when things get moderately more secure.
Decent SSL certs are expensive. Period. By decent, I mean one that is trusted out of the box by most browsers and client-side software that conducts transactions over http(s) like the Citrix clients.
Yeah, you can save money by buying a GoDaddy cert, but only if you have a hand in deciding which platforms will be accessing the resource. You'll be surprised how many mobile phone mail clients, SSLVPN clients - and while we're at it, Citrix clients, at least on mobile devices - require manual configuration to some degree in order to trust your cheap cert. In those cases you might've well have just gone with self-signed.
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.
Actually, not really. If you do it right, the performance impact from using SSL is negligible. Take a look at this article: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
Gmail was switched over to https, and this is what the folks who did this have to say about the performance impact (from the link above):
In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead.
Unfortunately, many CAs charge an extra fee for each Subject Alternative Name added to the certificate. It is also a pain for server admins to re-install a re-issued cert when SANs are added/removed from the cert.
That said, SAN is still better than one IP to hostname.
Working at an ISP that deals with school networks the most we need to make sure kids can't get to sites that aren't school related. Facebook, myspace, youtube, and twitter are some of the main sites blocked outside of porn and games. HTTPS is hell to filter. Since it is all encrypted you can't look at the packets and see where it is going. Sure you can filter by IP but then you have the headache with the akamai servers or the web server itself sharing the same IP as multiple other web sites. And we found a way to hijack the cert so we can look at the packets but that causes every SSL site's cert to come up as invalid and that is now a headache for the end users. Plus where is the privacy in that.
The cost is a pain too but I see most of you all have beaten that to death already.
https://slashdot.org
Its not possible for your ISP to cache any images/videos/anything you may be browsing while using HTTPS. If you're in a small country like New Zealand then your ISP pays a lot of money for international traffic. They pay for the peak bandwidth they use. Although they will never admit it, they rate-limit traffic at peak times. The alternative to rate limiting is caching. Personally I don't care if my youtube video comes from USA or my ISP's cache, I only care if it comes quicker than it takes to play it.
Regarding CPU bandwidth for encryption, this seems like an opportunity to plug my product.
The Nitrox security processors from Cavium Networks: For a couple of bucks and a couple of Watts you can encrypt 40Gbps. This is enough to offload encryption for a medium-sized data center using one tiny box.
http://www.caviumnetworks.com/processor_security.html
Not to mention Verisign only giving out 2048bit certificate, this makes much slower compare to 1024bit certificate.
I'll tell you why:
SSL is too much trouble for a small website. The certificates are expensive, and cover one URL - but I work extensively with subdomains, for example. My browsergame has it's own domain at battlemaster.org and then there's forum.battlemaster.org, bugs.battlemaster.org, etc. - I'd need either a very expensive wildcard certificate, or several.
Options such as CaCert exist, and I use it internally, but since it's not in all the major browsers, you can't use it anywhere where you will have non-geek visitors.
Assorted stuff I do sometimes: Lemuria.org
Economics: It costs money to have and to hold the necessary certificates for HTTPS.
Energy: It costs more CPU power and thus more actual electricity to do HTTPS.
Storage: It costs a little more memory to do HTTPS.
Since nothing we serve on any of our web sites is confidential it would be a waste of money, time and energy to bother with HTTPS. HTTP is sufficient for the vast majority of web sites.
There is a shortage of IP addresses, so many small (and even many larger) sites use virtual hosting for cost reasons. Dedicated hosts cost 3-4 times as much as shared hosting.
According to http://httpd.apache.org/docs/2.0/vhosts/name-based.html Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol.
Ergo, If I run a small website on a shoestring budget, I don't use SSL
No one uses SAN. SAN certs are not even purchasable for normal mortals, you have to get special accounts at the few places that do them, and each name is the 'full price' of the high end certs. It's not like you can throw five domain names in a $10 cert.
And I actually think you're wrong, IE6 supports SAN. In fact, I think IE5 supported SAN. SAN was actually part of X.509 from the start, and almost everything that supports SSL supports it. It was just DOA because it's not how certs are purchased and sold, and are purchased for individual domains, and no one is going to go add a new domain to their existing cert and get it re-signed. Anyone big enough to be doing SAN is big enough to dedicate IPs to start with, or just wildcard it
In fact, wildcard certs are about the only SAN certs you'll ever run into in the wild, so they can do example.com and *.example.com on the same cert. Otherwise, no, they don't exist. I actually think it would be interesting to try to find an actual SAN-cert signed site (Say that three times fast.) out there. Anyone got a link? (Remember, we don't need a login or anything to see the cert.)
The problem is XP's lack of SNI. That's pretty much it.
MS, once again, is fucking over web development by refusing to implement new standards that fix serious problems.
If corporations are people, aren't stockholders guilty of slavery?
To begin, we need gophers for our security
gophers://google.com seem to be down
You're right--I was getting a few things confused.
IE6 supports SAN on XP and above--and I believe on some lower versions of Windows, though I'm not really inclined to go see exactly which version first gained that support.
IE6 does not support SNI, which is somewhat irrelevant since the support has to come from the system libraries--which XP doesn't support. IE6 doesn't run on Vista (natively or in any supported configuration) and IE7+ on Vista+ supports SNI just fine.
That said, SAN certs are quite available to average mortals. Godaddy provides them for $90 to anyone with a credit card, for 5 names. As usual, prepurchase for several years and you get a discount. I purchased one a while back (for sites which have since been decommissioned) and it worked a treat, though since this was replacing 4 self-signed certs and was only for a small group of people, I wasn't worried about legacy compatibility.
For your information, they're also really good about modifications. You buy an n-site cert and can change names/resign until your year is up (or that's how they did it when I bought mine.) Also, you probably visit sites daily which have certs with SAN--for a while there, Godaddy was adding a gratis SAN of www.example.com whenever you purchased a cert for example.com. I don't know if they still do this, though a buddy thinks they still do.
Frankly, SAN was perfect for me. Although it was a tiny bit more expensive than I would have preferred (for my clients), it fit my hosting needs perfectly. I'm not "big enough" to get several IP addresses, but I was hosting about 30 websites for people, 4 of which wanted SSL. I passed the cost onto them, ate the temporal cost required to get everything configured, and everyone was happy.
It is possible with Server Name Indication which is supported by almost every browser except... drumroll... our beloved Internet Explorer on Windows XP.
http://en.wikipedia.org/wiki/Server_Name_Indication
Not yet sure if it does as well as other SEs, but it's good. Fall back on others.
"Tongue tied and twisted, just an Earth bound misfit
...slows down browsing, and who gives a crap, for most sites it doesn't matter anyway.
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
I've never heard of the godaddy deal, that actually sounds reasonable. I have heard of the www thing, but never found a place that did it, just the wildcard card having the non-wildcard thrown in.
Last I looked at the thing, a few years ago, it was so complicated and I couldn't actually purchase one, so I just went with three IPs.
If corporations are people, aren't stockholders guilty of slavery?
Because I want to cater to kids at https://clubcompy.com, I thought it would be important that the whole site should be https so that kids' sessions could not be hijacked or tinkered with. Maybe that was paranoid, but I hoped that parents would appreciate the care I was taking.
It was strange to have that move be received with skepticism by a few. Is 100% https somehow perceived negatively by users? Why? My site isn't slow; I have a hardware loadbalancer that takes the burden off my app servers.
Beyond that, making my site 100% https was a pain. My J2EE server didn't allow it by default, and I had to tweak it's default configuration to keep it from redirecting to an http address after the user authenticated. I had tons of problems getting google to index me, took weeks to even show up on search results. (Mostly because I was naive about all the things I had to do to make the site proper in terms of my hyperlinks and metadata.) Yes, the certificate costs money, and I'm not charging yet for service, so that hurt.
I dunno, I feel underappreciated and overworked for what I got out of the deal. :P
Dave
About 2000 "Redundant" mods.
Can't anyone read the other 100 posts about SSL needing its own IP address?
How many more years will slashdot have an off-by-one error on your Score in your profile?
The computational cost of setting up a SSL connection is not the problem. I'm sick of hearing this already. Do you think I have downloaded this page from slashdot? More likely from my ISPs cache. SSL breaks caching and will overly increase traffic and slashdot effect.
Simple question; while many defend some aspects of HTTPS as for privacy, authenticity, etc, the truth is, it uses a centralized models, where browsers are bundled certificates from "trusted organizations".
Others however, state "why should *I* trust such organizations, specially if they're susceptible to their local laws, and to compliance with their local government.
I can use HTTPS, but if the US government tells some-us-ca to issue a certificate for my domain, they'll be forced to do so.
Hence HTTPS is not infallible, it's both centralized, and susceptible to foreign laws, and policies of all the organizations that *your visitors' browsers* trust. (not just you).
EFF's HTTPS Everywhere... https://www.eff.org/https-everywhere
Works great IF the site implements HTTPS (and makes it easy for users to continue surfing without typing an extra "S"). Support for Firefox, I'm not sure about other browsers (site is down as of the time of this post)
If so then time will fix this problem
Mostly this mattered back in the days of dialup; I suppose there are a few people who still care. Unencrypted text compresses very well, which means that most web pages do. (Pictures, video, and downloadable binaries don't compress significantly because they have usually already been compresed.) If you're using some form of connection that does data compression, such as a V.90 modem, that compressibility significantly improves the performance of your connection; the boost can be a factor of 2 or more. Encrypted text does not compress, which means that you don't get that performance benefit.