Forgot your password?
typodupeerror
Firefox Privacy Security The Internet IT

Firefox Extension HTTPS Everywhere Does What It Sounds Like 272

Posted by timothy
from the effin'-sweet dept.
climenole writes "HTTPS Everywhere is a Firefox extension produced as a collaboration between The Tor Project and the Electronic Frontier Foundation. It encrypts your communications with a number of major websites. Many sites on the web offer some limited support for encryption over HTTPS, but make it difficult to use. For instance, they may default to unencrypted HTTP, or fill encrypted pages with links that go back to the unencrypted site. The HTTPS Everywhere extension fixes these problems by rewriting all requests to these sites to HTTPS."
This discussion has been archived. No new comments can be posted.

Firefox Extension HTTPS Everywhere Does What It Sounds Like

Comments Filter:
  • noscript? (Score:4, Informative)

    by Cmdr-Absurd (780125) on Friday June 18, 2010 @08:17AM (#32611540)
    noscript has a means of doing this on a per-site basis. Wildcards are accepted.
    • by Jojoba86 (1496883)
      I did not know that. However at least this user-friendly extension from the EFF will hopefully be a better solution for less technically inclined people, and be able to raise awareness of the difference between using http and https.
    • by Anonymous Coward on Friday June 18, 2010 @08:45AM (#32611738)
      Unfortunately. No https for slashdot.org - why not Slashdot? Comments on politically orientated stories from "sensitive" countries does not deserve to be encrypted? You should know better Slashdot
      • by Lingerance (1117761) on Friday June 18, 2010 @08:50AM (#32611780)
        That's a subscriber feature.
        • by FriendlyLurker (50431) on Friday June 18, 2010 @08:58AM (#32611844)

          That's a subscriber feature.

          So to narrow down people posting politically sensitive stories (say, whistle-blower type stories) from a country, it is merely necessary to cross check banking records against payments to Slashdot. Slashdot should know better.

          • by ConceptJunkie (24823) on Friday June 18, 2010 @10:11AM (#32612554) Homepage Journal

            It's not /.'s job to provide a secure means for posting politically sensitive stories. It would be nice if that's possible but that's not what they are in the business of doing, so I don't think it's fair to suggest /. "should know better".

            I'm sure they know perfectly well, and I'm sure that the decision support HTTPS this way is also an economic and technological decision. /. is a business, not a charity, and not a public service (although it provides public service as part of its business model). If /. advertised itself _primarily_ as a forum for free, uncensored speech or a forum for communicating with people in less free circumstances then it's a fair cop.

            It's one thing to suggest /. _should_ do this (and I think they should, all things being equal), but it's another to say (or imply) it is wrong for them not to.

            On the other hand, like Microsoft, busting on /. is fun and often justified, so I wouldn't mind piling on. They're such insensitive clods!

            • by ultranova (717540) on Friday June 18, 2010 @10:48AM (#32613050)

              /. is a business, not a charity, and not a public service (although it provides public service as part of its business model).

              Every time I hear "is is a business, therefore it doesn't have to care about anything besides profit" I turn a little more to the left. Seriously, did CEOs mistake Soviet propaganda as instruction manuals or something?

              It's one thing to suggest /. _should_ do this (and I think they should, all things being equal), but it's another to say (or imply) it is wrong for them not to.

              If it's not wrong for them to not do something, then why should they do it?

              • It's silly NOT to expect a business to care about anything other than profit. Profit is pretty much the sole determination as to whether a business survives.

                And there's nothing wrong with that. Once you ACCEPT that a business should only care about maximizing profit, then you understand how to get a business to operate in an ethical manner: Make it profitable.

                You can do that with consumer pressure, laws, taxes, penalties, subsidies, handouts....

                So don't get upset that businesses are only interested in pr

              • Re: (Score:3, Interesting)

                by jesset77 (759149)

                If it's not wrong for them to not do something, then why should they do it?

                Wait.. Let me make sure I'm getting your double negatives straight here. Are you saying that the amorality of an inaction robs motive from the corresponding action? It's not wrong for me to not eat a potato chip right now. So why eat a potato chip? Do I have to be arrested for setting the potato chip down before I can omnom with a clear conscience?

                Dewd, your world sux! I am glad I don't live there. ;D

            • by FriendlyLurker (50431) on Friday June 18, 2010 @11:24AM (#32613450)

              It's one thing to suggest /. _should_ do this (and I think they should, all things being equal), but it's another to say (or imply) it is wrong for them not to.

              You might be right. However we do not have to look far (e.g "Thailand Shuts Down 43,000 More Websites" [slashdot.org], or "FBIs Facebook Monitoring Leads To Arrest In England" [slashdot.org] both a few stories back) - to see that social network sites like /. are being sniffed, scanned, intercepted and profiles built up for normal citizens all around the world. 43,000 Websites have been shutdown or blocked in Thailand, and it would be naive to think they wouldn' also t sniff plain-text posted on those websites from Thai based IP's to identify problematic Thai citizens, who now may be on government watch list's - just waiting for a visit from local authorities, firing from Gov departments, or any other manner of persecution the regime see's fit to deal out.

              It might not be Slashdot's job or responsibility to offer even the most minimum technological security https offers to users - but it may reflect pretty poorly on Slashdot as a technology orientated social networking site - if they do not set a good example in the proper use of technology, who will?

      • why not Slashdot?

        Slashdot is a business. Always was (you never noticed the blatant product endorsements?), always will be.

        SSL certs cost money, and SSL connections cost CPU cycles. Remember how fanatical they were about banning people who reloaded the feeds too often (in their opinion)?

        Given that this site only just barely adopted CSS in the last year or two, I think you should wake up and smell the coffee: Slashdot is in Coast Mode. FSDN or whoever owns them right now is only interested in advert

        • Re: (Score:3, Informative)

          by Thing 1 (178996)

          SSL certs cost money

          In fact I just researched this, and found a site that sells a cert that 99% of the current browsers accept, for about $70/year (lower when purchased in bulk). Sure, that completely aligns with your statement -- it isn't free -- but your statement sounds more like Jamie Lee Curtis saying "Food costs money, rent costs money, things cost money Louie; you sleep on the couch" than it does "stop buying coffee at Starbucks for a month and it's paid for".

    • ...and I use NoScript regularly :)

      Still, for those of us who setup systems and browser for other people, a simpler extension like HTTPS Everywhere will help immensely.

    • by Anonymous Coward on Friday June 18, 2010 @08:50AM (#32611778)
      From TF (and missing) A [eff.org]:

      Our code is partially based on the STS [wikimedia.org] implementation from the groundbreaking NoScript [noscript.net] project.

    • Re: (Score:3, Funny)

      by Dishevel (1105119) *
      Would someone tell me how this happened? We were the fucking vanguard of websites in this country. Slashdot was the website to comment on. Then the other guy came out with https. Were we scared? Hell, no. Because we hit back with a little thing called httpss. That's got double t's and double s's. For security. But you know what happened next? Shut up, I'm telling you what happened—the bastards went to four s's. Now we're standing around with our cocks in our hands, selling tdouble t's and double s's.
  • by Coopjust (872796) on Friday June 18, 2010 @08:19AM (#32611554)
    http://noscript.net/features#options [noscript.net]

    Preferences for enhancing HTTPS behavior and cookies:
    Force the following sites to use secure (HTTPS) connections - a space-separated list of site patterns

    Then again, if you don't trust the NoSript author after the controversy [techjaws.com], this might be a good alternative. I figure NoScript is under more scrutiny than any other extension and the author learned his lesson.

    • by SuperBanana (662181) on Friday June 18, 2010 @08:37AM (#32611688)

      I don't care about ads on his site.

      I care about being forced to update NoScript every few days, each time being forced to load his site. I've got another extension, a Flash downloader that does the same thing. They're both either the world's worst programmers, or they're intentionally releasing updates just to drive traffic to their homepages.

      It's also incredibly irritating to get interrupted almost every time I go to restart Firefox!

      • by Anonymous Coward on Friday June 18, 2010 @08:42AM (#32611724)

        From the FAQ [http://noscript.net/faq]:

        2.5
        Q: I don't like NoScript redirecting the browser on its release notes page every time I upgrade it. Is there any way to prevent this?
        A: First time you install NoScript and every time you upgrade it to a newer major version, Firefox opens an additional tab containing the NoScript welcome page, where you can read the release notes, the latest announcements and an introduction to the most important NoScript features (plus a link to this very FAQ...)
        If you feel you don't need such heads up, you can disable this feature by clicking the NoScript icon, selecting Options and unchecking "Display the release notes on update" in the "Notifications" tab.
        Notice that if the above "fix" doesn't work or, worse, you keep being redirected on the welcome page every time you restart Firefox, chances are there's something (like a buggy extension) preventing your preferences from being saved: you may need to follow this advice, then.

      • by Coopjust (872796) on Friday June 18, 2010 @08:45AM (#32611730)
        http://noscript.net/faq#qa2_5 [noscript.net]

        Q: I don't like NoScript redirecting the browser on its release notes page every time I upgrade it. Is there any way to prevent this?
        If you feel you don't need such heads up, you can disable this feature by clicking the NoScript icon, selecting Options and unchecking "Display the release notes on update" in the "Notifications" tab.

        He's intentionally driving traffic to his page, but you can disable it easily (it used to require about:config, but it was a boolean that was fairly easy to find).

      • by j.sanchez1 (1030764) on Friday June 18, 2010 @09:15AM (#32611978)
        about:config
        set noscript.firstRunRedirection to false
  • Default to HTTP? (Score:5, Insightful)

    by SpazmodeusG (1334705) on Friday June 18, 2010 @08:20AM (#32611558)

    Geez. What kind of poorly written site would do something like quietly defaulting to unencrypted HTTP on a HTTPS request.

    https://www.slashdot.org/ [slashdot.org]

    • What kind of poorly written site would do something like quietly defaulting to unencrypted HTTP on a HTTPS request.

      Once the user has logged in, there are three reasons to switch back to HTTPS for any page that doesn't take credit cards or the like:

      • The ciphers in HTTPS take a not insignificant amount of CPU time. Not all web applications are database- or network-bound.
      • HTTPS isn't cacheable by intermediate transparent proxies, such as those used by dial-up or satellite Internet providers.
      • Google has not released a version of the Google Custom Search box that works on HTTPS sites. The last time I tried it, IE would show t
    • by suso (153703) *

      Maybe its because they want more control over what clients are doing? Using SSL consumes more CPU you know, on both the client and the server side.

      As a sysadmin for a web hosting provider, I see lots of these types of extensions that are written with no consideration of the server side of the equation. The people writing them seem to think that the server side has infinite CPU, RAM and bandwidth, which is just not true.

    • by e2d2 (115622)

      Poorly written because it defaults to HTTP? I disagree. Programmers like myself avoid using HTTP for delivering things that simply don't need to be encrypted. Why? Because it's more resource intensive on both the server and the client. We use the optimal solution - HTTP.

      • Re: (Score:3, Insightful)

        by profplump (309017)

        It's only the optimal solution for you. If the client choose HTTPS and you change back to HTTP then *you're* deciding that their content shouldn't be encrypted, even if they think it should be. You can choose not to offer HTTPS if you think the burden is too high on your end, but you're lying to yourself by calling it the "optimal" solution for both sides.

        You might not care that your web browsing is encrypted. But I might be on a monitored network and don't want my overlords to know that I downloaded a chee

        • by e2d2 (115622) on Friday June 18, 2010 @11:07AM (#32613266)

          You're shit out of luck because _we_ pay the bills here and _we_ build the websites so yes it's not being out of line to think that we should control how it's delivered. Take your entitlement to someplace that honors that currency. I'm a hacker too, but this whole "I want everything in the world my way" shit is getting old. Live with it, or don't. But it's not an "issue" in any way as far as I'm concerned. Don't like it? Go elsewhere.

  • Link? (Score:2, Informative)

    by Anonymous Coward

    For those of you without google ... http://www.eff.org/https-everywhere

  • by Jojoba86 (1496883) on Friday June 18, 2010 @08:21AM (#32611564)
    Oh wow, this is awesome. I've used greasemonkey scripts with facebook but it's pretty ugly, seems to load the http page before the https page. This sounds perfect. Here's the link https://www.eff.org/files/https-everywhere-latest.xpi [eff.org] which is missing from TFS.
    • by Fnkmaster (89084) on Friday June 18, 2010 @08:28AM (#32611616)

      Hmm... if you are trying to encrypt your communications with *Facebook* something tells me you are worrying about the wrong people getting their hands on your personal data.

      • I'm sorry, but while OP may be concerned about Facebook, it's naive of you to think that s/he has separate passwords for other sites vs. FB - remember, we're talking about someone on the internet. I even use the same password in some places, but regardless it's either SSL login or no login or, if its somewhere I really want to login (/. for example), I use a username/password combo that I don't use anywhere else. Security's role shouldn't be diminished just because of the site you're going to - if there is

        • by tepples (727027)

          if there is a login box, HTTPS should be offered

          The certificate company and the hosting company charge annual fees for HTTPS. These are a cost of doing business if you're deriving a significant chunk of revenue from the site. But how should the operator of every little blog and forum afford the annual fees for HTTPS?

          • While a very valid point, there is nothing to stop someone from self-signing a cert. Of course, having something signed by a CA carries a lot more weight, but if I trust the site and the owner/author makes it clear as to why they self-signed and provided a means of ensuring some amount of trust, I would feel much better. And like I said, at least use a different username/combo for those kinds of sites than something you use in more secure situations.

            • While a very valid point, there is nothing to stop someone from self-signing a cert.

              There is also nothing to stop someone from performing a man-in-the-middle attack on a self-signed HTTPS connection any more than an HTTP connection. You could start your own CA, get the CA's certificate to your users somehow (this is the hard part), and then sign your SSL certificates with that CA's key.

            • While a very valid point, there is nothing to stop someone from self-signing a cert. Of course, having something signed by a CA carries a lot more weight, but if I trust the site and the owner/author makes it clear as to why they self-signed and provided a means of ensuring some amount of trust, I would feel much better. And like I said, at least use a different username/combo for those kinds of sites than something you use in more secure situations.

              This was a great suggestion until the major browsers added the "super scary warnings". I've had to walk so many people through exactly what to do in order to get past those. Especially the type of people that say I typed in my password ROSEBUD just like I always do and I got this message. Those errors are too scary for the average user, and require too many clicks.

      • by Tim C (15259)

        It also stops MITM attacks of course - while it's unlikely that anyone would intercept my latest status update or message and change it in flight, with HTTP it's possible.

        (Not that I care, but that's one reason why the OP might.)

      • HTTPS usage is at least as much about preventing surreptitious alteration (facilitating 'unwanted features' and attacks) of web pages. This can happen on unsecured or compromised networks: the 'coffee shop' Wifi scene is a place where people are particularly vulnerable not just to sniffing but to intrusion/infection attacks.

        Then again, imagine you've been browsing safe at home and what was this tiny extra ad space that your ISP inserted into the top corner of many web pages became slowly larger over a perio

    • Here's the link https://www.eff.org/files/https-everywhere-latest.xpi [eff.org] which is missing from TFS.

      This is a link to the extension. Here is the link to the article:
      https://www.eff.org/deeplinks/2010/06/encrypt-web-https-everywhere-firefox-extension [eff.org]

  • by Nick Fel (1320709) on Friday June 18, 2010 @08:27AM (#32611600)
    ...except not "everywhere", just major sites.
  • by gouttonio (1700654)
    ... how does this work without risk of compromising the data at the end of the tor route if the webserver won't accept https. I'll be waiting for SPEEDY which looks like a cleaner way of encrypting everything.
  • by Culture20 (968837) on Friday June 18, 2010 @08:33AM (#32611652)
    It can't work unless these sites already have an https version. If they redirect all 443 traffic to 80 like /., then it does nothing. It might work for facebook since it has a couple pages that allow https, but I'm sure things like their photo servers are probably http only.
  • Link (Score:5, Informative)

    by muffen (321442) on Friday June 18, 2010 @08:33AM (#32611654)
    • Re: (Score:3, Interesting)

      by Nixoloco (675549)
      Another extension that some might find useful is SSLPasswdWarning [mozilla.org]. It evaluates password input fields and pops up a warning whenever they post via non HTTPS.
  • by roman_mir (125474) on Friday June 18, 2010 @08:36AM (#32611676) Homepage Journal

    Firefox itself does not really make it easy for the users or for admins to use https everywhere.

    I just made a small site, it's for a business, that runs everything through https, I redirect http to https completely. Firefox 3.6.3 on Windows had no problem running the site. IE on windows couldn't open the encrypted pages, Firefox 3.5 on any GNU/Linux distro couldn't open them either, to fix this, I had to add this to /etc/conf.d/ssl.conf : SSLInsecureRenegotiation on

    That fixed the IE and FF3.5 on Linux problem.

    Here is the description of this flag from apache mod_ssl directive description page:

    SSLInsecureRenegotiation Directive
    Description: Option to enable support for insecure renegotiation
    Syntax: SSLInsecureRenegotiation flag
    Default: SSLInsecureRenegotiation off
    Context: server config, virtual host
    Status: Extension
    Module: mod_ssl
    Compatibility: Available in httpd 2.2.15 and later, if using OpenSSL 0.9.8m or later

    As originally specified, all versions of the SSL and TLS protocols (up to and including TLS/1.2) were vulnerable to a Man-in-the-Middle attack (CVE-2009-3555) during a renegotiation. This vulnerability allowed an attacker to "prefix" a chosen plaintext to the HTTP request as seen by the web server. A protocol extension was developed which fixed this vulnerability if supported by both client and server.

    If mod_ssl is linked against OpenSSL version 0.9.8m or later, by default renegotiation is only supported with clients supporting the new protocol extension. If this directive is enabled, renegotiation will be allowed with old (unpatched) clients, albeit insecurely.
    Security warning

    If this directive is enabled, SSL connections will be vulnerable to the Man-in-the-Middle prefix attack as described in CVE-2009-3555.
    Example

    SSLInsecureRenegotiation on

    The SSL_SECURE_RENEG environment variable can be used from an SSI or CGI script to determine whether secure renegotiation is supported for a given SSL connection.

    I wonder if there are other ways of making this work with my other directives:

    SSLEngine on
    SSLCipherSuite HIGH:MEDIUM:!aNULL:+MD5

    SSLVerifyClient none - I am thinking about switching it to 'require' right now, but will have to test all browsers with it again, but have to do it I think.

    Oh, and getting it all to run together with apache httpd with mod_ssl + mod_jk + apache tomcat is quite a hassle.

    But most unfortunate thing about FF is how it treats the self-signed certificates. It shows it as an SSL ERROR, to which exceptions must be made for the user to be able to enter the site. Can FF developers think about this fact for like longer than a second? It is not an error to run a site with a self-signed certificate, it is a configuration choice and it provides an important role to the site: encrypted traffic for login and for the data transferred to and from the client.

    Why is FF showing this to the users as an error? This is not an error, this is by design and it is a special case of usage. Who is not frustrated by the browser treating self signed certificates as if they are some sort of a disease? They provide an important role - a way to secure communications between the server and the browser.

    Can this be looked at, because I am SURE this prevents various sites from using encrypted traffic in the first place and it is a BAD thing, not a good one. All traffic needs to be encrypted, but especially user name/password traffic shouldn't be sent around in plain text.

    Name it what it is: an exceptional case of using security to encrypt traffic, a case where the site may not necessarily be what it wants to be seen as, but at least the traffic is actually encrypted. It's terrible if someone comes to your site just to see: SSL ERROR on it, OF-COURSE admins don't want THAT message to be shown on their sites, why do you think so few sites do security properly?

    • It is not an error to run a site with a self-signed certificate

      A man in the middle could insert his own self-signed certificate, decrypting the traffic from your site and reencrypting it with his own key pair, and users would be none the wiser. One workaround is to start your own CA, sign its root certificate with PGP, and distribute that cert to your users to install. But then that starts to depend on the PGP web of trust, which in turn depends on air travel to get keys signed.

      • by roman_mir (125474)

        It is still not an error of SSL or of the site, it is a configuration choice.

        • by bunratty (545641)
          Yes, it is a configuration choice. With that configuration choice, Firefox cannot determine that it's communicating with the site it thinks it's communicating to, and warns the user about the potential security problem.
          • by roman_mir (125474)

            This is not an error of ssl or of http, this should come with a warning from a browser, no question, but my users will know the site and the cert.

            I completely disagree that this should come with a label 'Error'.

            It should come with some label like: 'Warning, the certificate is self signed, you better know what it is'.

            However you skipped completely the part of my post, where I am talking about the real issue:

            SSLInsecureRenegotiation on

            which is in itself prone to MITM type of attack, regardless of whether the

      • by Bazer (760541)
        A self-signed certificate may be unsafe but it does imply an intent of privacy.

        With effort, and sometimes a trivial amount, one can invade on another's privacy. But we've all made a social agreement to respect privacy; all it takes is a humble token, like a window curtain, to remind us of this. The curtain is just cloth, but it does an excellent job of affording us privacy, because it asserts our intent. That way, if we're able to detect it, we can be certain in knowing that our privacy is violated -- otherwise, any access we didn't think to deny (but would regret later) might accidentally intrude upon us -- and with no ill will from the innocent onlooker! How foolish of us, that we didn't draw the curtain when we had the chance!

        • by tepples (727027)

          A self-signed certificate may be unsafe but it does imply an intent of privacy.

          So in other words, a self-signed certificate is security theater [wikipedia.org]. Online criminals by definition don't respect the "social agreement" that you mention. (By the way, whom are you quoting?)

          • by Bazer (760541)
            Security and privacy are two different things. You won't stave off criminals capable of carrying out a MITM with a self-signed certificate. You can, however demonstrate that you intend to keep this session private, just like you would a conversation. If worse comes to worst, you'll have a much easier way of proving ill intent on the part of a misbehaving eavesdropper like an ISP or a shoddy data retention scheme.
            • you'll have a much easier way of proving ill intent

              Proving to whom? Losing something and using the court system to get it back can be too expensive for individuals or home-based businesses. SSL is cheaper than a lawyer.

      • It is not an error to run a site with a self-signed certificate

        A man in the middle could insert his own self-signed certificate, decrypting the traffic from your site and reencrypting it with his own key pair, and users would be none the wiser.

        So that just means that the site isn't secure. Fine. FF shouldn't display the lock icon, or color the address bar. But that's no reason to treat the connection as an error. The appropriate thing to do is to present the site as insecure (which it is), but to go ahead and encrypt the link. Ideally, FF should go one step further and use SSH-style server key history. Silently (or with a small "new key, do you want to accept it?" dialog) accept and use the self-signed certificate, and then puke hard if the certificate ever changes without good reason (i.e. old cert expired or was replaced with a proper certificate).

        By making these small changes, browser makers could significantly increase the average security of the web, so that sites that will otherwise have to go with unencrypted HTTP can use HTTPS -- even if MITM attacks are still possible, and if security shouldn't be relied upon, this sort of "opportunistic" encryption can make casual snooping significantly harder. That's a good thing.

        • Re: (Score:3, Informative)

          by Rich0 (548339)

          Agreed - security isn't all-or-nothing. It is like having a builder refuse to put a lock on a house door, because the house has windows without bars so the lock is just false security.

          By all means the browser should communicate the relative security of a connection, but an ssl connection with a self-signed cert is NO LESS SECURE than a non-ssl connection. The errors generated by a browser would imply that the non-ssl connection is actually more secure. Indeed, if you want to mitm a bank you're probably j

    • Re: (Score:3, Informative)

      by Culture20 (968837)

      But most unfortunate thing about FF is how it treats the self-signed certificates. It shows it as an SSL ERROR, to which exceptions must be made for the user to be able to enter the site. Can FF developers think about this fact for like longer than a second? It is not an error to run a site with a self-signed certificate, it is a configuration choice and it provides an important role to the site: encrypted traffic for login and for the data transferred to and from the client.

      Why is FF showing this to the users as an error? This is not an error, this is by design and it is a special case of usage.

      Because to verify a self-signed cert, every user has to call the site maintainer on the phone. Self-signed certs or Corporate CAs are great for in-house use where the sysadmins can install the certs for everyone, but since FF can't tell whether your unrecognized cert is being used to just feed html data to a user, or if the user is being asked to enter something confidential, it can't make a distinction between a reasonable use for self-signed and a MitM attempt. Since bad admins had been training people

      • by roman_mir (125474)

        But this is not an ERROR, this is by design and should come with some warning. But an error? No, if the user knows the certificate and the site this is just a warning.

        • by Culture20 (968837)

          But this is not an ERROR, this is by design and should come with some warning. But an error? No, if the user knows the certificate and the site this is just a warning.

          It _is_ just a warning. If the user knows the cert info (maybe printed on paper in front of him), he can verify it and add it to an exception list. I do that all the time for my own test servers. Firefox doesn't prevent people from connecting with self-signed certs, it just makes them think about the ramifications before they do.

        • by tepples (727027)

          if the user knows the certificate

          How would the user know the certificate on the user's first visit to the site?

          • by roman_mir (125474)

            Because of my business case - the site is for users who must be first set up by the site administrator, so nobody can just show up, it's only for known users.

            so they will also be notified on what the appropriate certificate is.

            • by tepples (727027)

              Because of my business case - the site is for users who must be first set up by the site administrator

              And you can have all these users install your CA certificate when they sign up.

            • by xaxa (988988)

              Because of my business case - the site is for users who must be first set up by the site administrator, so nobody can just show up, it's only for known users.

              Then I suggest you add the self-signed certificate to their computer, something like this [cacert.org].

    • Sending your login/pass to an unauthenticated server is not any better than sending it through HTTP. If you have a MITM, he can be faking the website.

      If you want secure login, either get an authenticated cert or use OpenID and let the user choose his provider.

      • by roman_mir (125474)

        It's not an error, it should be a warning. My users will know the site and the certificate number and this IS how I want the site to work, I don't need a CA or an OpenID to do this, it's not wrong to do.

        And it is a million times better than sending plain text over any line any day.

    • Re: (Score:3, Insightful)

      by Burz (138833)

      Why is FF showing this to the users as an error? This is not an error, this is by design and it is a special case of usage. Who is not frustrated by the browser treating self signed certificates as if they are some sort of a disease? They provide an important role - a way to secure communications between the server and the browser.

      It is an error in judgment on Mozilla's part. Their increasing institutional-mindedness is causing them to send users always into the arms of the CAs -- preferably with no exceptions. The mindset has blinded them to the fact that is it a relatively straightforward UI design issue. Speaking of which, if I were in charge at Mozilla the first thing I would change about the cert warning dialog would be to display the server's fingerprint so its immediately in the user's face. Imagine if websites could publicize

      • mod this guy up (Score:5, Insightful)

        by Sloppy (14984) on Friday June 18, 2010 @11:18AM (#32613384) Homepage Journal

        How ridiculous is it, that people get their bank's identity vouched for by a third party they have never met and don't know anything about, when the bank could just put up a fingerprint sign in their lobby and on their paper statements? And people say using a CA is more secure, and less vulnerable to MitM? Really?!?

  • facebook (Score:2, Interesting)

    by aneamic (1116327)
    Am I the only person getting a 'chat is disabled on this page' bubble everywhere when using this plugin on facebook?
    • No. And I consider it to be a feature, not a bug.
    • Re: (Score:3, Informative)

      by Culture20 (968837)
      Facebook's chat feature is http-only. My guess is it was a simple way to keep chat from working on the password reset pages (to prevent chat from stealing focus while typing in a password).
  • by HTMLSpinnr (531389) on Friday June 18, 2010 @09:43AM (#32612264) Homepage

    1. For classic shared hosting solutions using name based hosting, I can almost guarantee if you hit https:/// [https], you're going to hit someone else's virtual host. Many cheap hosting providers w/ limited public IPs will load up domain names on a single IP/Port, but still provide secure hosting to one domain name (on the same port) for shopping cart checkout under a different domain name. Using such a plugin in this use case would not work so well. Then again, would most "smaller sites" really be worthy of encryption in the first place?

    2. Not every site is designed w/ the same content root in http vs https. Switching from http to https may completely break if the file structures under the two virtual hosts (potentially entirely separate in Apache) aren't identical (i.e. pointing to the same directory). I'm not touting that this is a best practice, but would be completely feasable if you wanted to keep specific content from being accessed via http and didn't want to bother with mod_rewrite or equivalent.

    To the poster above who says there's little CPU penalty for SSL, SSL may not be taxing on the client, but hundreds or thousands of sessions on a server (especially one hosting an app, DB, and Apache) may be another story. Why is someone's assumed paranoid that someone will see that they're reading about cars or home theater equipment on a forum worth requiring a service owner to scale his hardware to the next level to maintain acceptable performance (assuming this phenomenon is multiplied hundred-fold)?

    • Re: (Score:3, Informative)

      by HTMLSpinnr (531389)
      Woops, that should be https://www.[my lame site].com

Going the speed of light is bad for your age.

Working...