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.
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)
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.
For the company I work for it's because Certs cost money, and self-signed certs are a pain for users.
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.
Oh. Ok.
Well, I've still got all those other reasons to never sign up with them.
Technoli
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
I just always visit https://www.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.
which is totally what she said
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.
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.
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
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.
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.
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.
---- Teach Peace. It's Cheaper Than War.
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.
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.
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.
"I opened my eyes, and everything went dark again"
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?
Certificates form TTP's aren't free.
Never say never. Ah!! I did it again!
They have secure logins, just not secure sessions after you've logged in.
And that's an important distinction. It means someone can sniff your credentials for the *session*, and impersonate you as long as you're logged in; but if you detect the mischief, then you can regain control, because your real long-lived credential (your password) is sent under ssl.
It's a tradeoff, but for something non-critical it seem to me like a reasonable one.
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.
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.
...because browsers don't support SSL-enabled virtualhosting yet?
You old-timers probably also remember the web back when it was computationally uneconomic for your ISP and an unknown number of its commercial and/or three-letter buddies to data-mine your every click... Why, back in your day, there probably weren't even massive multinational botnets bouncing zero-days off every likely-looking bit of code in your system.
chat was disabled
Sigh... I considered that a feature.
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
Except that they both work on https now. Just throw an s in there and it keeps chugging along. In FB, you can actually tell it to do this.
i hear in the next privacy settings reset facebook will start publishing your current session cookie by default.
"If still these truths be held to be
Self evident."
-Edna St. Vincent Millay
During the handful of times that I've actually been to their homepage (none of which has been recent, and usually having been redirected there from somewhere else), I never really paid attention to it.
Technoli
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.
Verislime still ultimately "runs" PKI.
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.
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.
I just always visit https://www.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.
According to my (school age) son, https farks up some of the precious facebook games discouraging the kids from using it. If this is true, its not good, kids are probably the ones who most need https, I'm not totally surrounded by people who think it would be hilarious to 'crack' my account with firesheep and post 'funny' stuff on my wall.
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.
This is the problem though.... without viewing the source code you have no idea.
From their login page if you look at the url you'll see http
Its only after you log in that you see https
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?
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.
This is addressed using Server Name Indication (https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_Indication) - unfortunately this is not supported by Internet Explorer when running on Windows XP.
If you are happy to potentially exclude that chunk of browsers (i.e. tell then to upgrade to Firefox/Chrome/what-ever for free, upgrade to Vista/7 at cost, just put up with the certificate warnings, or just go away) then the shared IP address issue is a solved problem.
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,
I would love to see CACert in the default CA databases widely, that would help a lot.
The root certificate used by startssl to sign their free certificates is in most OSs' default list of trusted root certificates these days (http://en.wikipedia.org/wiki/Startssl#StartSSL). It might not be totally reliable for Windows users (for IE on XP at least it depends on them having the "root certificates update" patches installed, and they are not marked as critical or important so may not be installed everywhere), but seems to be an increasingly practical option as XP+IE market share continues to fall.
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.
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).
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.
1) Granny's not going to pay $100s per year for her blog.
Granny's block doesn't really need encrypting under its own name though (which is a fault in the question, rather than your answer). For reading it is no doubt public information that needs no protection. For protecting logged in sessions when she is making updates she is probably using a service like Blogger anyway and can edit using their domain even if she has her own domain name associated with the block for readers to access it through. Chances are she doesn't have her own domain anyway and her blog is themusingsofagranny.someblogsite.com or someblogsite.com/themusingsofagranny so her site can use the blog provider's (wildcard) certificate anyway. In no way should Granny need to pay for a cert for this. Anyway, startssl's free certs are accepted by the majority of browsers these days (http://en.wikipedia.org/wiki/Startssl#StartSSL).
2) Processing overhead. Security comes at the cost of speed.
The processing overhead is very small on modern CPUs - before the CPU becomes a significant bottleneck in this regard other parts of your infrastructure will have long since become a problem. There is extra latency in the initial negotiations, but that is only per session and should not be a problem for a decent web server, a decent client, and all but the slowest of connections. Content caching (or lack thereof) could be an issue, but proper use of cache-control headers will mitigate this for the most part (not something Granny needs to worry about - a good blog software setup should handle it without her even knowing the issue might exist).
That is one of the reasons people are busy deploying DNSSEC so we can put certificate-information in DNS and verify that. It will take years ofcourse before it gets deployed.
New things are always on the horizon
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 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
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.
I don't strictly need any other reasons, but reasons like "don't want my personal information shared with anyone who pays Zuckerberg for it" and "utterly pointless" still exist nonetheless.
Technoli
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
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.
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.
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
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.
If you own the client computers and the network they run on, why not add your own CA root cert to the browsers and make your own CA *the* authoritative CA and man-in-the-middle all silent like?
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
Facebook always uses HTTPS for logins, so your password is never sent in the clear anyway.
Unless your tweets are protected there is very little obvious reason to use https for twitter, since they would all be public anyway, and the login does use https.
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?
Facebook does not encrypt the cookies so its vulnerable to session hijacking This process has been automated with a firefox plugin (Firesheep) so any 12 year old could do it.
Oddly enough we can thank the Tunisian Government for rollout of https on the whole session.
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).