Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Networking Security The Internet News Your Rights Online

Why Doesn't Every Website Use HTTPS? 665

suraj.sun writes "HTTPS is more secure, so why isn't the Web using it? You wouldn't write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection that's essentially what you're doing. There is a better way, the secure version of HTTP — HTTPS. But if HTTPS is more secure, why doesn't the entire Web use it?"
This discussion has been archived. No new comments can be posted.

Why Doesn't Every Website Use HTTPS?

Comments Filter:
  • by realityimpaired ( 1668397 ) on Monday March 21, 2011 @10:03AM (#35558614)

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

  • Cost-benefit (Score:5, Insightful)

    by Shoten ( 260439 ) on Monday March 21, 2011 @10:07AM (#35558672)

    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.

  • by dkleinsc ( 563838 ) on Monday March 21, 2011 @10:07AM (#35558676) Homepage

    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.

  • by SCHecklerX ( 229973 ) <greg@gksnetworks.com> on Monday March 21, 2011 @10:07AM (#35558684) Homepage

    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.

  • by EasyTarget ( 43516 ) on Monday March 21, 2011 @10:14AM (#35558808) Journal

    "That so-called webmasters think they are guarding access by only encrypting/authenticating the login amuses me."

    ..which is why you need to let real webmasters get on with it and not try it yourself. We are protecting -something-; it's your loss if you cannot work out what that is.

  • Except the sites that offer HTTPS are the highest traffic sites on the web: facebook, gmail, twitter.

    You are dead wrong.

  • by Sancho ( 17056 ) * on Monday March 21, 2011 @10:29AM (#35559006) Homepage

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

  • Re:Correct (Score:4, Insightful)

    by ElusiveJoe ( 1716808 ) on Monday March 21, 2011 @10:32AM (#35559040)

    True.

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

  • Re:Correct (Score:5, Insightful)

    by JWSmythe ( 446288 ) <jwsmytheNO@SPAMjwsmythe.com> on Monday March 21, 2011 @11:28AM (#35559880) Homepage Journal

        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.

An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.

Working...