Posted
by
CmdrTaco
on Monday March 21, 2011 @08:58AM
from the asked-that-more-than-once dept.

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.

The fact that it can muck up cheap-n-cheerful 'zillion sites on one host' arrangements unless everybody's TLS ducks are in a row probably counts as a fairly significant cost, as well. Especially on the low end.

It already works [wikipedia.org], although there are issues with older browsers and libraries not supporting it. I happen to use SNI for my stuff, but unfortunately others cannot afford to lose compatibility with older browsers.

This is the main reason we have not been implementing it. Our environment relies heavily on caching and loadbalancing. We are trying to find ways around it though, especially to get all session-data to use HTTPS (but a requirement is that users are not scared with warnings about part of the content being unencrypted).

Even with the mighty Google I can see the lag while using the secure version. And secure Wikipedia version stops working sometimes. Hell, I'm writing this on a website without HTTPS, maybe/. web masters could answer why is it like that, too.

Protip: If users don't give enough of an airborne copulation at a ventrally rotating pastry to choose passwords that aren't brain-meltingly stupid, then they don't care about encrypted transport to/from the web servers, and there's no point in eating the added costs

But as we've seen proven, the CPU load isn't as big of an issue as is claimed.

The reports where people said it was, were from an awful long time ago, discussing high loads and CPUs that were measured in Mhz (i.e., Ghz CPUs weren't even imagined yet).

Right now, we have to look at a few issues.

1) Users are familiar with typing http:/// [http] . If you went https only, without a redirection from http:/// [http] you'd lose traffic. Simple fix, do a redirection.

2) Not everyone supports https still. If you include a piece from a 3rd party, you'll either get a broken lock, or the 3rd party data won't show.

3) Google Adsense doesn't support it. Still. And people have been asking for years. They are a major revenue source for a lot of sites.

4) Hosting https sites still require a unique IP for each site. If I, a a hosting provider, have 1000 sites on a server, I'd rather use one IP, than 1000 IPs.

5) SSL certs must be renewed. You must have the cooperation of the provider. Certs are no longer $100/yr, if you shop around a little. Trustico [trustico.com] has provided perfectly functional certs for $20/yr for a long time (with discounts for multi-year purchases). I've been using them for several years. For a blog that has very cheap hosting, even the $20 doesn't necessarily make sense.

6) The time where there were huge compatibility issues with SSL implementations in browsers is gone, but you will still find the occasional app that doesn't have SSL compiled in by default, but that has become rare. At very least, all modern browsers support https:/// [https] out of the box, regardless of where you are at.

The biggest issue is, users don't generally care. On my site, I have a warning every page if you're viewing insecure, and encouraging you to click the link to switch to the https version. Less than 10% of the users ever switch up to the https version. The only time I enforce it is when a users logs in. When they try to log in, it forces them to https, and keeps them there for the duration of their session.

On point #4, it's been awhile since I played with webserver setup, but SSL certificates for public sites are usually tied to the server DNS name, not its IP. I'm pretty sure this means you can have more than one webserver/hostname entry, all with the same IP, and use host header names (IIS) or Name-based Virtual Host Support (Apache/others) to determine which site and certificate to connect the user to.

"I'm pretty sure this means you can have more than one webserver/hostname entry, all with the same IP, and use host header names (IIS) or Name-based Virtual Host Support (Apache/others) to determine which site and certificate to connect the user to."

... and you would be incorrect. Name-based Virtual Hosting cannot be done with HTTPS. The reason is that the name of what is being requested is also encrypted in the SSL data. The only way for a web server such as Apache to know what virtual host to use is to look at the name. In order to get the name it would have to SSL decrypt the request. In order to SSL decrypt the request it needs to know what SSL key to use. In order to know what key to use, it would need to look it up in the name-based virtual host record. In order to do that, it needs to know the name... oops.

The spec changed. The implementations did not. Given IE's continued browser market share dominance and lack of support on still prevalent platforms, this can't be done without breaking compatibility. *shrug*

If you are going to switch back over to http, you might as well not bother in the first place. HTTP, being stateless, one need only sniff that session ID, and they are now in. That so-called webmasters think they are guarding access by only encrypting/authenticating the login amuses me.

You cannot depend on the user's IP address not changing. Besides offering only some additional security (most people subject to having their session sniffed are using the same public WiFi as the user - so they'll actually have the same IP address), more importantly, some users have load-balanced outbound Internet access.

On our own network, we see legitimate single sessions bridging multiple A-class networks. Page request to page request they will have an IP address from a wholly different ISP, which can even geolocate to wildly different locations. Admittedly that's the exception rather than the rule, but it's also becoming more common - especially for people on mobile networks, whose IP address is subject to whichever cell tower is giving them the strongest signal right now. Users sitting relatively equidistant from multiple towers can flip between various IP's rather frequently.

The only things you can reliably depend on not changing in the user's request (for legitimate users) are also all spoofable by illegitimate users. For example, you can depend on a cookie not changing unless you told it to change, but it can be spoofed; you can depend on the user agent not changing, but it can be spoofed, and so forth.

There is no way to make an unspoofable session cookie; you can only prevent interception by using a secure standard such as SSL.

I think you missed the point. Not only does it fail to provide any protection in the most likely interception scenario, but for that lack of protection, it also breaks the site for legitimate users. A little added security for no user inconvenience is ok - as long as you're realistic about the small protections it offers, but it's decidedly less ok when real users find they're unable to use your site as a result.

You can make it harder to pick the locks (sniff session tokens) by nailing your front door shu

I suspect that some are merely clueless, and some are mostly concerned with preventing persistent "lockout" type attacks at the lowest possible cost. You'll notice, for instance, that most sites that authenticate over HTTPS, then drop back to HTTP, go back to HTTPS and demand the original password if you try to do things like change the password(and possibly certain other operations considered sensitive), even if you have the session ID.

Obviously, that does nothing to prevent assorted public-wifi hilarity; but it makes it comparatively difficult(difficult enough that social engineering or just guessing that the password is 'password123' because they always are is easier) to permanently compromise the account and generate a customer support/being flagged as a spam host cost problem.

Webmasters who think that this is actually good security are fools. Webmasters who think that it blocks a certain class of especially costly attacks, while being much cheaper than full HTTPS, are entirely correct. And, given how little one pays for access to many sites that do this, they probably don't care too much unless something attracts mainstream attention *cough*firesheep*cough*...

They may not be guarding access, but they are guarding against an eavesdropper discovering the password. Sure they can session hijack after switching back to HTTP, but they don't have the password. This fact could be leveraged further by requiring the user enter the password (and transition to HTTPS again) whenever something important like changing password, email, or making a monetary transaction is done.

That said, I do agree that switching back to HTTP while still logged in is still a bit silly.

Actually, the main reason why the password is https but the session ID is not so important is because people recycle their passwords, and session ID's are merely temporary. So it is sensible to keep a user's actual password encrypted, but not worry about the session if there is little to do other than browse the catalog or post a comment. Whenever any action requiring HTTPS such as final checkout is called up again, then often a good site will ask for the password again and not trust the session ID from HTT

This. Lots of page accesses = lots of processing power spent on encryption and decryption. Not everyone can afford hardware cards to do the encryption.

Second, proper certificates costs money, and you "kind of" need one static IP for each website - it's a big hard for a person to justify the need for one IP for each of his 10 blogs - most companies will only issue a block of 8 IPs (5 usable) to a single server.

Server Name Indication has been supported by major browsers for 4 years. Browsers have supported Subject Alternative Name certs (which bypass the need for one IP per name) for nearly 8 years. At this point, the one cert per IP issue should be well addressed.

The cost of the SSL certificate to make the HTTPS work has been the most common issue I've ran into. Penny-pinching administrators can't be convinced it's a justifiable expense. And they nickel and dime you for every service the certificate is "good for" such as email.

Static IP addresses aren't a problem, one IP can host a variety of completely different domain names, the server sorts out the requests based on the entire URL being requested, including the domain name. And there's nothing that says that y

You don't need a separate IP for each domain. The apache web server can have multiple sites on one IP, each with a different SSL certificate. It just decides which site and certificate to use based on the site name in the http request.

How is that possible since the Host: header is hidden in the SSL stream and the web server can't accept and decrypt the SSL request until it has the right certificate.

It's called SNI (Server Name Indication), it's part of the SSL standard, and has been supported in Apache since 2.2.12. The virtual host name is submitted as part of the TLS negotiations so the server knows which certificate to use.

"HTTPS" is more or less setting up a SSL link and running plain ole HTTP over that secure link.

No the SSL encryption layer is done before the HTTP layer does it's thing. So if you identify your vhost as part of the HTTP header, then you're not going to know your vhost name until after the SSL is already set up and working, classic chicken and egg problem.

HTTPS/SSL a good argument for going ipv6 where there is no particular shortage of ip space.

No: The way HTTPS works when the "recent" SNI feature is not available is that the TLS stream is created (including certificates being negotiated and verified) before any hostname information is transferred. This means that you can only have one valid certificate per publicly addressable IP address without SNI.

But yes: With SNI (see http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org] for info) the hostname is sent earlier, so the server can lookup the right certificate for that name and send it instead of relying on a 1-to-1 mapping between IP addresses and service names.

Well, probably not quite yet: Unfortunately SNI is not completely supported by all common user agents, particularly any version of Internet Explorer running on Windows XP, so whether you can justify using the feature right now depends a lot on who your target audience are. If you don't have any users browsing your content/app with XP+IE or you don't mind telling such users to upgrade to FF/Chrome/other, upgrade Windows, or just put up with the certificate warnings, then using SNI will work for you. You run the risk of sending XP+IE users away though, which might not be acceptable if your bottom line relies on getting as much traffic as possible through your doors.

Speaking as someone who has run more than one SSL site on one host, you're correct. You open separate ports. Our method of choice to make those into non-ugly addresses was to

1) get the cert for a nice name like www.bleh.com2) Create a Netscaler/F5/whatever SSL VIP that load balances webhost.bleh.com:9999 and webhost.bleh.9998, etc and presents it as one IP address on port 443. Make sure that each webhost httpd is using the cert for www.bleh.com. Also, you can load the SSL cert on the load balancer usual

It used to be noticeably slower to access a site via https than by http, even accessing the same page.

However, now we have server processors which operate in the GHz, and which run in multiples. Heck, we have that even for tiny home PCs and now phones. Servers are apt to be instances on clusters or clouds these days. So I don' think there is a major penalty for using https.

If your traffic is huge enough that you will notice the hit: then you really should be using https anyway. If you're serving that kind o

The article goes into this a bit. While crypto processing requirements are a small factor, the big deal really is the share-the-same-ip browser-reliant virtual hosting that people decided to use even though it was a crummy hack to start with. The Internet totally relies on it at this point. If you try SSL to such a site, there's no way for the server to choose the correct SSL certificate for the virtual host you are trying to reach -- because that information is not transmitted until the HTTP session is

- 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.

To protect against a man in the middle attack. The certificate ensures you are connecting to the server at the end and not some intermediate or impostor that's relaying the messages or posing as the server.

Why is there no mode with encryption, but without the bother of an SSL certificate at all?

Because that would provide no assurance that you are communicating with the server at the end and not some evil computer in between you and that server. It would make the

For large hosters, SSL key distribution and updates becomes a problem when using large server farms or CDNs. Doing SSL in hardware on load balancers solves this for server farms, while CDNs are a more difficult problem.

Those are the main reasons. Latency and CPU usage are not deal-breakers today, though they are a factor.

The certs from StartCom are whatever you generate for them to sign. Last year they accepted 1024 bit RSA and 2048 bit RSA. LIke the rest of the SSL vendors, in 2011 only 2048 bit RSA certs are allowed for issuance, and full transition to 2048 only certs by 2013.

Secondly, the 128 or 256 bit symmetric crypto has nothing to do with the SSL cert or provider, that's software settings on the host. 128 bit AES is widely considered secure against attacks for the next 20 years or so, and 256 bit should be secure for the as far into the future as we can guess. http://www.keylength.com/ [keylength.com]

The (in)security I refer to has to do with the level of checking into who you are. Basically, they just send an email to administrator type address at the site you want a cert for, and if you get the email you are assumed to be the admin. This can be attacked easily through DNS flaws or just signing up for a webmail account with an address that the SSL provider thinks sounds like an admin account. This happened to many of the large webmail providers before they started blocking the common admin accounts for registration.

XKCD was right. The common attacks are against the humans who run your DNS or mail providers, not that the crypto is weak.http://xkcd.com/538/ [xkcd.com]

There are reportedly free certificates through StartCom [startssl.com], 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 [wikipedia.org], 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.

That's why I never got on the https bandwagon. I couldn't self-sign without generating error messages in the browser, and none of the content that I served at the time had any need to be secure. It was self-publishing, for crissake, effectively vanity publishing.

Come to think of it, so is everything on facebook, twitter, and most other websites, including this one. I guess it's not really important for almost anyone.

I have an idea- if you need something to be secure, don't use HTML or HTTP at all. Use a

A lot of people don't realize that the SSL handshake takes place before the client sends the host field to Apache or IIS. The server has no idea what site you are requesting. That means that if you have a virtual server with 200 sites then only one of those 200 can have an SSL cert. Can "Joe's Webhosting" ask for 199 IP addresses? What if all small and medium hosts did that? We'd hit the IPv4 address limit faster than we already are doing.

Nowadays "real" certificates are not expensive anymore. Certificates from "Comodo" were in the past offered for as little as USD 5 per year. Currently they can be had to USD 9,95 for one year for example at www.litessl.de (Disclaimer: I'm not affiliated with this company but a happy company of their "main" operations under a different name).

While some SSL vendors try to put these cheap certificates into a bad light (because they are issued in a automatic process, certain data is not included into the certif

How is it Microsoft's responsibility that people are still using a ten year old operating system?

Calling XP a 'ten year old operating system' is hyperbole. Until Vista, it was the latest OS that Microsoft was shipping, so it's been under five years since there was a replacement available, four since Vista was available to the general public (January 2007). The system requirements for Vista were so high that it wasn't shipped with a lot of entry-level machines, especially netbooks. Microsoft was still shipping XP until January 2009 - two years ago.

They aren't exactly expensive though. Slight pain in the ass to set up, but not that bad. I just use a self signed cert on our own site since it's only employees that need access to the private section.

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.:)

You're kidding, right? You can pick up a single site SSL certificate for under $20 and a wildcard certificate for about $100. For all the other costs associated with running a website, the cost of an SSL certificate is negligible.

You don't need to be doing e-commerce to have data worth protecting. If nothing else, half your users probably use the same login and password for your site as they do for their email, their social networking and p

The problem is that the SSL negotiation happens before the HTTP session begins so there is no Host header available when the server has to cough up a certificate.

There are really only 3 options for HTTPS virtual hosting:1) Wildcard certificates if all the sites are in the same domain2) SAN certificates if the certificate ifs purchased with up to 5 names on it3) An extension to SSL called SNI that sends the host information in the SSL negotiation.

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.

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 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.

Part of this was discussed long ago [slashdot.org], with browsers treating self-signed certificates worse than they treat plain unencrypted traffic, even when passwords are passed around in plain text, nothing will change, because it is a major PITA to deal with browser issues as well as with CAs.

Here is a hint: create more incentives to use HTTPS, not fewer, and more people will use them.

This is not going to be fixed until stupid browsers stop treating a new connection to a website, that is using a self-signed certificate as some sort of a virus, while absolutely not doing the same for plain HTTP connections.

THe problem is that the browsers persist under the myth that certs can ONLY be used for proving the identity of a host; and completely disregard the fact that an equally valid and completely unrelated task is traffic encryption.

The trouble is, identity checking and encryption are inseparable.

Public key encryption doesn't allow Bob to securely exchange data with Alice: it allows Bob to securely exchange data with someone claiming to be Alice who has given Bob what she claims to be Alice's Public Key.

Without some way for Bob to verify that the person claiming to be "Alice" is, indeed, the real Alice that's about as much use as an ashtray on a motorbike.

Where self-signed certificates are useful is when you've independently verifie

Browsers exploding in fury when self-signed certs show up is a design decision to protect stupid users from themselves. Otherwise, Joe Sixpack is going to start blindly 'trusting' every self-signed cert he sees just to get the dialog box/popup whatever out of the way, just like he already blindly clicks 'ok' when faced with those fake antivirus popups.

Actually, it's nowhere near as bad as everyone is making out. Sheesh, what a bunch of fussy fusspots.

You have a deliberate "mitm" (otherwise known as a proxy) that has ALL of the certs (or, indeed, just one cert, since the object is to encrypt traffic, not necessarily strongly authenticate it). It can be multi-homed or it can have virtual hosts, it really doesn't matter worth a damn. This front-end box then runs plain HTTP requests to the actual server(s) hosting the content within the network.

Today one of the major reasons is that IE on XP does not support the SSL/TLS extensions for virtual hosting.When he says,"it's only partially implemented" he means everywhere but IE(any version) on XP.http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org]

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. 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.

The cost of security certificates from Verisign, et al. are expensive and self-signed certificates show up as big scary browser warnings to the ignorant masses where as standard unencrypted offers no such sca

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.

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."

1. The great majority of small sites (which an earlier poster has said "wouldn't notice the extra load") run on shared servers. The hosting company certainly would notice the extra load, they'd need more servers, therefore more electricity and floorspace, therefore higher costs, therefore hosting price goes up. Probably rather substantially.

2. HTTPS requires 1 IP address for every site you host. (There is the SNI extension but if this article [techrepublic.com] is to be believ

If SSL (really TLS as SSL 3.0 is really becoming a dead protocol) can be broken, you must assume it already has been and that the only safe strategy is to get it broken in public so that it can be fixed. In other words, you want ubiquitous encryption and you want it as heavily tested as possible.

(This reminds me of a story. Apparently, Rolls Royce were not impressed with the reliability of their Merlin engine, so they'd take one at random, ramp it up to full power and leave it until something burned out or

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?

I just always visit https://www.facebook.com [facebook.com]. Seems to work. There is also a setting I noticed that says something like "use secure sessions wherever possible", which perhaps redirects you to the https site even if you click on an http link. I haven't tested it though, I'm happy using https all the time so that people can't steal my session cookie or whatever.

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.

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.

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.

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?

[blockquote]I would have hard a time recommending to anyone to run their whole site in SSL. Get the logins or most forms in SSL, but the rest would be overkill.[/blockquote]

While most of your post is correct, not that part. Encrypting the login without encrypting the rest of the session is virtually completely pointless, since you leave your users vulnerable to session replay attacks. Yay, I don't know your password! Who cares, I have your authentication token.