Become a fan of Slashdot on Facebook


Forgot your password?
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 Anrego ( 830717 ) * on Monday March 21, 2011 @09:59AM (#35558566)

    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.

    • Yep, the one-line answer is:

      It's too CPU-intensive for the server.

      Cost could be an issue but it's like $100 a year? Hardly a problem for anything but the most amateur of blogs.

      • Re:Correct (Score:5, Informative)

        by fuzzyfuzzyfungus ( 1223518 ) on Monday March 21, 2011 @10:11AM (#35558746) Journal
        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.
      • Re:Correct (Score:5, Informative)

        by isopropanol ( 1936936 ) on Monday March 21, 2011 @10:14AM (#35558794) Journal

        Also, HTTPS does not play well with proxy caches or load balancing.

        • Re:Correct (Score:5, Interesting)

          by dropadrop ( 1057046 ) on Monday March 21, 2011 @11:29AM (#35559898)

          Also, HTTPS does not play well with proxy caches or load balancing.

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

      • Re:Correct (Score:4, Insightful)

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


        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.

      • The correct answer is that since everybody chooses either "password", "123456" or "iloveyou" to guard their life secrets then there's no point in encrypting anything.

      • Re:Correct (Score:5, Insightful)

        by JWSmythe ( 446288 ) <jwsmythe@jwsmy[ ].com ['the' in gap]> 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 [] has provided perfectly functional certs for $20/yr for a long time (with discounts for multi-year purchases). I've been using them for several years. For a blog that has very cheap hosting, even the $20 doesn't necessarily make sense.

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

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

        • Re: (Score:3, Interesting)

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

          There's still the occasional hiccup in recognizing certificate authorities, even big ones. My cell phone c

          • Re:Correct (Score:5, Informative)

            by skelly33 ( 891182 ) on Monday March 21, 2011 @12:43PM (#35560972)
            "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.
    • by SCHecklerX ( 229973 ) <> 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.

      • by Anrego ( 830717 ) *

        I would assume in cases like this, they set the SSL bit in the cookie and do whatever web voodoo is necessary such that the cookie gets sent over ssl.

        Then again, I've seen some pretty boneheaded stuff security wise on the web... maybe they don't!

      • by fuzzyfuzzyfungus ( 1223518 ) on Monday March 21, 2011 @10:17AM (#35558848) Journal
        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*...
      • by Zorpheus ( 857617 ) on Monday March 21, 2011 @10:23AM (#35558924)
        The use of encrypting the login is that the passwords are save from being sniffed. Too many people use the same password for multiple sites.
      • by mmj638 ( 905944 )

        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.

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

      • by v1 ( 525388 )

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

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

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Most websites are virtual hosts on a single server. SSL does not support more than one certificate per IP address/port.

      • by Malc ( 1751 )

        1) Isn't SSL done on a per domain name basis?
        2) Can't virtual hosts be NATed or something and each domain given it's own private IP address?

        • by vlm ( 69642 ) on Monday March 21, 2011 @10:26AM (#35558954)

          1) Isn't SSL done on a per domain name basis?

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

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

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

        • by asdf7890 ( 1518587 ) on Monday March 21, 2011 @10:41AM (#35559182)

          Isn't SSL done on a per domain name basis?

          No. But yes. Well, probably not quite yet.

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

          But yes: With SNI (see [] 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.

      • Apparently you haven't heard of the fix [].
    • 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

    • by skids ( 119237 )

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

    • Re: (Score:2, Insightful)

      by stonecypher ( 118140 )

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

      You are dead wrong.

    • by mmj638 ( 905944 ) on Monday March 21, 2011 @10:29AM (#35559000)

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

  • Certificate? (Score:4, Interesting)

    by Lord Lode ( 1290856 ) on Monday March 21, 2011 @10:01AM (#35558592)

    Maybe because it requires certificates that cost money and annoy users when they expire?

    • Re:Certificate? (Score:5, Informative)

      by spinkham ( 56603 ) on Monday March 21, 2011 @10:14AM (#35558796)

      Free certs are available, and every bit as (in)secure as the paid standard ssl certs. []

      The "annoying users when they expire" is a symptom of the main problem.

      Well, actually it's 2 problems.
      For small hosters, IE(any version) on XP doesn't support SSL/TLS on virtual hosts. Everybody else does. []

      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.

    • 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.
  • Cost (Score:2, Informative)

    by isorox ( 205688 )

    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)

    • by kju ( 327 ) *

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

  • For the company I work for it's because Certs cost money, and self-signed certs are a pain for users.

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

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

    • Subject says it all. It's expensive to get a signed SSL certificate.

      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

  • by kae_verens ( 523642 ) on Monday March 21, 2011 @10:03AM (#35558616) Homepage

    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)

    • by Ferzerp ( 83619 )

      Show an example of something properly configured that it doesn't work on please. If you do it properly, IE will have no clue you're serving sites based on host-headers.

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

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

        The OP is referring to the fact that SNI is far from universal

    • IE7 and newer, for the record, do support SNI; so long as you're on Windows Vista or Windows 7.

  • by The MAZZTer ( 911996 ) <megazzt&gmail,com> on Monday March 21, 2011 @10:04AM (#35558632) Homepage
    ....every [sub]domain needs a dedicated IP for the certs to work properly.
  • 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.
  • 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.

  • long discussion (Score:3, Interesting)

    by roman_mir ( 125474 ) on Monday March 21, 2011 @10:07AM (#35558680) Homepage Journal

    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.

  • by Anonymous Coward

    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.


    • by Amnenth ( 698898 )
      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.
    • by jd ( 1658 )

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

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

      The advantage

  • It's XP's fault. (Score:5, Interesting)

    by spinkham ( 56603 ) on Monday March 21, 2011 @10:07AM (#35558688)

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

  • SSL issues (Score:4, Interesting)

    by thetagger ( 1057066 ) on Monday March 21, 2011 @10:08AM (#35558692)

    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.

  • by mother_reincarnated ( 1099781 ) on Monday March 21, 2011 @10:08AM (#35558694)

    1) SSL certificates are not free
    2) SSL key exchanges are horribly expensive compared with serving a web page
    3) Right now EVERY web site would require a unique IP address

    Enough reasons?

  • Some reasons (Score:5, Interesting)

    by jolyonr ( 560227 ) on Monday March 21, 2011 @10:08AM (#35558696) Homepage

    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.

  • 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

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

  • At the end of the day it's all about the money.

    1. The cipher algorithms request processing power which translates to fewer pages served per unit of processor resource.
    2. Standard page compression utilized by web servers to keep bandwidth low no longer works... fewer pages served per unit of network resource.
    3. 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, because I paid money to GoDaddy, Comodo, Verisign or whoever and they'll corroborate."

    The problem i

  • 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 believ

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

    • by jd ( 1658 )

      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

  • by holophrastic ( 221104 ) on Monday March 21, 2011 @12:58PM (#35561230)

    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?

  • by Snaller ( 147050 ) on Monday March 21, 2011 @10:55PM (#35568022) Journal

    ...slows down browsing, and who gives a crap, for most sites it doesn't matter anyway.

When you go out to buy, don't show your silver.