Slashdot Mirror

← Back to Stories (view on slashdot.org)

HTTPS Everywhere Gets Firesheep Protection

Posted by timothy on from the mitigating-malicious-mutton dept.

coondoggie writes "The Electronic Frontier Foundation today said it rolled out a version of HTTPS Everywhere that offers protection against 'Firesheep' and other tools that seek to exploit webpage security flaws. Hitting the streets in October, Firesheep caused a storm of controversy over its tactics, ethics and Web security in general. Firesheep sniffs unencrypted cookies sent across open WiFi networks for unsuspecting visitors to Web sites such as Facebook and Twitter, and lets the user take on those visitors' log-in credentials."

77 comments

  1. Do Not Use Unsecured Wireless by Anonymous Coward · · Score: 0

    As simple as that.

    1. Re:Do Not Use Unsecured Wireless by Logic+Worshiper · · Score: 0, Offtopic

      I don't give a rats ass if somebody else in the cafe also wants to know the weather, or also wants to read about Linux concepts...

      Don't use unsecured wireless for sensitive stuff.

    2. Re:Do Not Use Unsecured Wireless by MachDelta · · Score: 1

      B-b-b-but how am I supposed to get on teh intertubes at school? :(

    3. Re:Do Not Use Unsecured Wireless by Anonymous Coward · · Score: 1

      This is the kinda post someone who does not live outside their own box and doesnt understand how the rest of the world works, and who doesnt understand the the majority of people have zero idea how technology works.

    4. Re:Do Not Use Unsecured Wireless by Anonymous Coward · · Score: 1, Insightful

      I don't give a rats ass if somebody else in the cafe also wants to know the weather, or also wants to read about Linux concepts...

      Don't use unsecured wireless for sensitive stuff.

      All stuff is sensitive. Would you like to have e.g. your windows updates guid sniffed and used by some middle east or wherever guys later? Then you=them in terms of tracking by certain agencies, etc.

      windowsupdate.microsoft.com: To provide you with the best possible service, Windows Update also tracks and records how many unique machines visit its site and whether the download and installation of specific updates succeeded or failed. In order to do this, the Windows operating system generates a Globally Unique Identifier (GUID) that is stored on your computer to uniquely identify it.

    5. Re:Do Not Use Unsecured Wireless by Anonymous Coward · · Score: 2, Informative

      It's actually pretty common, and possibly even the norm.

      You can't just use a pre-shared key, so you have to use WPA enterprise. (a PSK is only slightly better than open, for privacy, if everyone knows it, and not terribly useful for regulating access to the network if you only want school affiliates to use the wireless resources).

      Often times you can't use the more common EAP types because the authentication data isn't stored in a way that's friendly to your radius servers.

      So now you have to write all sorts of documentation like "download this application that will take over your laptop's wireless card and you'll lose all your old network configs" or "Look for how your wireless card's supplicant configures EAP, and chose EAP-TLS, and then if it asks, select from the list of trusted certificate authorities verisign." Now get this information to all the users without standing around with out hiring a town crier, and hope that users actually read *and understand* the information when they don't even know if they've got a 32 of 64 bit system...

      So, while it is simple for you to configure your linksys wireless network at home, it isn't nearly as easy in the real world.

    6. Re:Do Not Use Unsecured Wireless by Anonymous Coward · · Score: 0

      In my country all to me known schools and universities only provide secured wireless, wpa2 + mac-filter. Yes, you need an admin for that. And yes, it's worth it.

    7. Re:Do Not Use Unsecured Wireless by bunratty · · Score: 4, Informative

      It's not as simple as that. The traffic is encrypted only during one part of the way from your computer to the server, so cookies can be sniffed anywhere from the wireless router to the server. But it is as simple as using HTTPS. Then all traffic is encrypted all the way from your computer to the server, and you also have the stronger guarantee that your computer is talking to the server you think it is, so you cookies cannot be sniffed by third parties. StartSSL offers free SSL certificates to allow any site to encrypt all of its traffic.

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    8. Re:Do Not Use Unsecured Wireless by Anonymous Coward · · Score: 2, Informative

      Enterprise or Pre-shared key WPA? Pre-shared keys are only marginally better than open, if everyone knows the key. If I know the PSK, I can force you to rekey your session then your traffic is unencrypted to me and I can use firesheep on you.

      And the fact that they use "mac-filter" leads me to think it is just PSK.

      That isn't to say these mechanisms are completely worthless, but they're not super-valuable.

      And I stand by my initial statement -- enterprise WPA in a university setting where you don't manage the end stations is hard.

    9. Re:Do Not Use Unsecured Wireless by Anonymous Coward · · Score: 0

      My uni uses WPA2 Enterprise with PEAP, and so do several other major institutions in Australia. Our connection details are stored in the staff+students database (I assume this holds all the different hashes needed for different services).

      Configuration doesn't seem to be a major issue: there is a collection of how-to guides for different OSs, and with the summary of the configuration details, it is pretty easy to use the GUI tools most OSs provide anyway.

  2. Does browsing wikipedia work now? by CryptoKiller · · Score: 1

    Does wikipedia work with HTTPS Everywhere now? I had to disable it because of all the 404 error messages I was getting.

    1. Re:Does browsing wikipedia work now? by somegeekynick · · Score: 1

      I did not have problems with accessing Wikipedia, ever. However, the suggestions feature in the search box for Wikipedia as well as Google stopped working ever since 0.2.2 (for me, anyway). 0.9.0 has not rectified this situation.

    2. Re:Does browsing wikipedia work now? by Anonymous Coward · · Score: 0

      That was a feature.

  3. And the ISP will sniff you. by Anonymous Coward · · Score: 2, Informative

    There's no substitute for end-to-end encryption.

    1. Re:And the ISP will sniff you. by tepples · · Score: 1

      here's no substitute for end-to-end encryption.

      I agree. But practically, even with a source of cheap or free TLS certificates, how does one establish end-to-end encryption for passwords on blogs, forums, and the like without paying extra for a hosting plan that includes a dedicated IP address? Name-based virtual hosting on HTTPS doesn't work with pre-SNI clients such as Windows XP.

    2. Re:And the ISP will sniff you. by Lennie · · Score: 1

      Don't use passwords, use OpenID ? I guess you can still hijack sessionids, so that is useless.

      But SSL/TLS isn't perfect either. Any root-CA or sub-CA can issue any certificate.

      We would atleast still need something like DNSSEC to validate what is stored in DNS. So that we can store in DNS, not just the A- or AAAA-record, but also which CA is allowed to sign your certificates.

      Even then, if you choose an external CA, it has pretty much been proven that governments can still get certificates from them.

      Do you trust the government of the country where you get your certificates from ?

      For the next couple of years, without a DNSSEC-validating client in the browser and some protocols to support it, we are pretty much fucked.

      --
      New things are always on the horizon
  4. Duh? by girlintraining · · Score: 2, Funny

    Wait, unencrypted signals sent over the air with your password and login is bad? If only someone had told me... /snark

    Seriously though: Unencrypted. Open. Network. Come'on guys.

    --
    #fuckbeta #iamslashdot #dicemustdie
    1. Re:Duh? by The+MAZZTer · · Score: 4, Informative

      Firesheep never used login credentials. It never needed to. Session cookies were enough to impersonate another user... so any visit to any HTTP page on any site allowed a Firesheep user to impersonate you on that site in theory (of course if you're logged out this is of limited use, but if you're logged in they can impersonate you without login details).

    2. Re:Duh? by blueg3 · · Score: 4, Informative

      Many of the sites that Firesheep attacks use HTTPS for their login, so you don't send your credentials in the clear, but fall back to HTTP for delivery of content. The point Firesheep attempts to make is that this is not sufficient -- your unencrypted HTTP requests contain the session cookie that your encrypted login obtained. The session cookie is just as useful, as long as you make use of it "soon".

    3. Re:Duh? by leptechie · · Score: 2, Informative
      The extension forces requests to be sent over SSL/TLS for all communication, as long as the site supports it. Works on Facebook, even Google searches, so yes this is a useful countermeasure. Of course, it is wholly dependent on the site supporting HTTPS in the first place.

      I've tried similar extensions, and Facebook gladly connects over HTTPS when manually instructed to, but reverts to normal HTTP on pretty much any click, this just keeps the connection on HTTPS regardless of the link target. The only downside, specifically on FB but certainly similar problems on other sites: no chat. So there are compromises, but probably worth it.

    4. Re:Duh? by damaki · · Score: 1

      There is a chrome extension working around that.

      --
      Stupidity is the root of all evil.
    5. Re:Duh? by moonbender · · Score: 1

      Does that work for Google, too? In other words, can you simply use the session cookie sent when performing a Google search to log into a Gmail session? The former is typically http, the latter https. I'm aware that you can use https for searching, too, I'm just wondering. Isn't there some kind of policy that segregates https cookies from http cookies?

      --
      Switch back to Slashdot's D1 system.
    6. Re:Duh? by Bucky24 · · Score: 1

      Having used firesheep myself, I can tell you that it doesn't work to login to gmail. I was able to sniff my own google account (using a separate computer), but was not able to get past my iGoogle homepage. Attempting to go to gmail prompted a login, even using the firesheeped session cookie. I think I may have tried google docs too, and it also required a login, but I am not sure about that one.

      --
      All the world's a CPU, and all the men and women merely AI agents
    7. Re:Duh? by Lennie · · Score: 1

      Their is also a bug in Chrome when you start up it will connect to the google.com-domain to check for updates and do so over HTTP and the problem with this is, it will also send the normal cookies associated with google.com. Which might give the attacker enough information to get into your igoogle/gmail account.

      --
      New things are always on the horizon
  5. Probably breaks lots of web sites by defaria · · Score: 2, Interesting

    Stated simply, many web sites just can't handle https.

    1. Re:Probably breaks lots of web sites by oodaloop · · Score: 4, Informative

      Um, no. That would be pretty dumb. IF the site has an https page, it directs to that. If not, it doesn't.

      --
      Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
    2. Re:Probably breaks lots of web sites by budgenator · · Score: 1

      HTTPS take more processing power to encrypt and decrypt the traffic, frequently enough traffic flowing through marginally usable server will completely crash and burn if all of the traffic were encrypted; it's like normal traffic would cause a site to be /.ed.

      --
      Apocalypse Cancelled, Sorry, No Ticket Refunds
    3. Re:Probably breaks lots of web sites by spidr_mnky · · Score: 1

      That sounds like a big opportunity for a man in the middle to tell you your site doesn't support ssl. That's still fine against passive listeners, but wouldn't it make more sense to it like flashblock and noscript do? Force ssl by default, and if that doesn't work ask the user if he wants to go with plain http. That would at least give you the opportunity to say, "Gee, gmail usually has ssl ..."

  6. How does HTTPS Everywhere do it? by Bromskloss · · Score: 2, Interesting

    Does it parse the webpage you are on and rewrite every link to use HTTPS or, better, does it intercept every request Firefox makes and rewrite that before it is sent?

    The reason I'm interested is that I want to create an extension that does rewrites in the latter way described, but don't know how to do it.

    --
    Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
    1. Re:How does HTTPS Everywhere do it? by Logic+Worshiper · · Score: 1

      It's pretty simple, you can often force https simply by typing it in the address bar, if the site has some kind https cert set up, it'll bring you to a secured version of the site. https://twitter.com/ works and brings to twitter securely, as it does for many mail sites. All you have to do is add a character the html string, which isn't that complicated. For it to really be secure, the server administrator has to secure their site.

    2. Re:How does HTTPS Everywhere do it? by Kozz · · Score: 1

      If you don't find your answer in forums, there's nothing stopping you from looking into the extension yourself, in most cases. Take the XPI file,change the extension to .zip (presuming you're in windows) and extract its contents. View source of the .JS files, and there you have it.

      --
      I only post comments when someone on the internet is wrong.
    3. Re:How does HTTPS Everywhere do it? by Anonymous Coward · · Score: 0

      The latter. They complained that Chrome does not let them hook into the networking component, so a similar add-on is impossible for Chrome. It may rewrite links, too, but that would not protect against external/manually typed in URLs or requests made via Javascript.

    4. Re:How does HTTPS Everywhere do it? by Anonymous Coward · · Score: 1, Insightful

      It does the latter. Requests are intercepted and converted according to pre-defined and user-definable rulesets before being sent.

    5. Re:How does HTTPS Everywhere do it? by Anonymous Coward · · Score: 0

      For it to really be secure, the server administrator has to secure their site.

      That's one of the things it helps to fix. For sites that are sending content or links to other pages beyond your initial page that you type in https, it tries to force all content as https first.

    6. Re:How does HTTPS Everywhere do it? by Bromskloss · · Score: 1

      The latter. They complained that Chrome does not let them hook into the networking component, so a similar add-on is impossible for Chrome. It may rewrite links, too, but that would not protect against external/manually typed in URLs or requests made via Javascript.

      Excellent! What is the documentation for learning how to do this? Or, as a backup, where in the code for HTTPS Everywhere is the relevant piece of code?

      --
      Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
  7. rtfa by Anonymous Coward · · Score: 0

    it just forces https on the server (like that other firefox plugin, "Noscript".)

  8. CA's are the problem, not the crypto by muckracer · · Score: 1

    SSL = Great
    SSL + some 600 MITM-Orgs your browser "trusts" = Bullshit

    Use HTTPS Everywhere anyway. Great plugin. But forget your much-touted "sense-of-security" because it can't exist in light of the above.

    1. Re:CA's are the problem, not the crypto by Logic+Worshiper · · Score: 3, Insightful

      A self signed certificate would be fine for most of what HTTPS Everywhere does.

      End to end encryption is for stuff that really matters, not facebook and other crap that's public to the internet anyway.

    2. Re:CA's are the problem, not the crypto by Anonymous Coward · · Score: 0

      Yeah, certs are mostly a scam, the better way to go would be to pick 15 random FF clients and read the cert for the page you are going to, if all 15 match (or 12 of the 15, let 3 of them be actively MITM'd) then you are unlikely to be being MITM'd or the MITM attack is so widespread as to be ubiquitous. This way FF only has to trust itself (and its copies on other people's machines). Then Self-Signed certs wouldn't be an issue (unless the site itself is fake (eg. welllsfargo.com).

    3. Re:CA's are the problem, not the crypto by Onymous+Coward · · Score: 2, Interesting

      Here's a way of handling certs which doesn't rely on those organizations: Perspectives

      http://www.cs.cmu.edu/~perspectives/

    4. Re:CA's are the problem, not the crypto by Steeltoe · · Score: 1

      You can be fired over someone cracking or spoofing your Facebook identity. I would consider that important.

      Who decides what security is important, really?

      --
      http://www.debunkingskeptics.com/
    5. Re:CA's are the problem, not the crypto by tepples · · Score: 1

      A self signed certificate would be fine for most of what HTTPS Everywhere does.

      But then how would your users know that your self-signed cert is authentic before installing it into their browsers for the first time? MITM in the wild is a reality.

    6. Re:CA's are the problem, not the crypto by Anonymous Coward · · Score: 0

      The problem is, by only encrypting "stuff that really matters", you're pointing a finger at that data and saying "this is the important stuff". Meaning, an adversary can devote all of his/her time to cracking that and ignoring the unimportant bits. Worse, this doesn't protect you from traffic analysis. Encrypting everything is the correct answer, not picking and choosing.

    7. Re:CA's are the problem, not the crypto by Lennie · · Score: 1

      DNSSEC is the solution for that, but it will take years before we'll have validating resolves in the browser.

      In studies it has been shows, even many DSL-routers block DNS over TCP or large DNS-packets.

      --
      New things are always on the horizon
    8. Re:CA's are the problem, not the crypto by Lennie · · Score: 1

      I don't know and who validates the response from the Perspectives notaries (the agents in the networks which store this information) ?

      And what about my privacy ? Do they store the information about the sites I visit (they probably say they don't).

      Maybe Certificate Patrol is a good start:

      https://addons.mozilla.org/en-US/firefox/addon/6415/

      It works like SSH, everytime you connect it will tell you if something changed since you last connected. It also will tell you what changed.

      --
      New things are always on the horizon
  9. Exactly the reason Firesheep was created by Anonymous Coward · · Score: 0

    This was exactly why the author released this tool, so that some one would fix the security shortcomings within current authentication.

    1. Re:Exactly the reason Firesheep was created by muckracer · · Score: 1

      I can't wait for CAsheep....

  10. Actions you must take for firesheep protection by Fnord666 · · Score: 2, Informative
    According to the release notes, there are specific actions that you must take to enable some of this protection:

    The 0.9.0 release of HTTPS Everywhere is a new beta version designed to offer improved protection against Firesheep. Most notably, it can provide much better protection for Facebook, Twitter and Hotmail accounts, as well as completely new protection for bit.ly, Dropbox, Amazon AWS, Evernote, Cisco and Github. Unfortunately, in order to obtain maximum Firesheep protection, especially on Facebook, you must take two extra steps:

    • Turn on the "Facebook+" rule. You can do that in the Tools->Add Ons->HTTPS Everywhere->Preferences menu. It isn't on by default, because it can cause Facebook Apps to raise errors. We're still waiting for Facebook to fix this, and the chat problem :(.
    • Install the Adblock Plus Firefox extension too, and use it to block the insecure http:/// adds and trackers that Facebook (and other sites) sometimes include.
    --
    'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
    1. Re:Actions you must take for firesheep protection by pyster · · Score: 1

      The release notes maybe incorrect, or dated, as it was on by default for me. the amazon rule is not, and has (buggy) next to it.

  11. Most average users don't use addons by Anonymous Coward · · Score: 0

    It's back to the problem that most people don't dick around with addons. If you're too lazy to go to https instead of http, I'm betting you don't use addons. 95% of the time I see an average user with addons, it's some stupid facebook or yahoo "toolbar" that they didn't even know they where installing and is now mucking up their system.

      This should have been defaulted years ago. Bandwidth and CPU power are both cheap enough these days that the extra overhead for encryption is a moot point.

  12. Re:Apps? by pyster · · Score: 3, Insightful

    If you are using an open wireless you have the same http/https issues everyone else has, regardless of the device you are using.

  13. 14 minutes 58 seconds...... by Anonymous Coward · · Score: 0

    Seriously, has this thing hit it's time limit for being a "hot" story yet???
    Sidejacking.... NOT new
    Use encryption.... NOT new
    Time till this story hits a fever pitch with the world and some security researcher (read as some monkey who took an already developed, tested, and researched idea and made it a PLUGIN)starts screaming "OH NOES THE INTERWEBZ HAS THE FAILXORS!!!" ... About another 2 years, just like last time.

    All this ranting and raving over this is about the equivalent of saying:
    "Hey, you know people can get into your house if you leave the door unlocked?"
    OMG. NO, REALLY????
    "For real man, every place that has a door can have this problem"

    It's stupid, this story is WAY past old, the technology is old, the method is old, there's already been publicly available tools (that are stupid easy to use, on both widows and *nix) out that handle this for like 2 years. Can we please PLEASE stop acting like this is in ANY WAY, SHAPE, OR FORM news? /rant

  14. Re:Apps? by Don_dumb · · Score: 1

    Thanks but I am unclear do the apps use http or https to communicate?
    Is there any way of knowing what security the apps are using to communicate with the service.
    This is important to consider as I haven't seen an iPhone app have an option of securing their connection with remote services. Most people use apps for things like facebook and are entirely at the liberty of the apps' security. There is no 'use https' choice if it doesn't do so.

    --
    If this were really happening, what would you think?
  15. Secure cookies by fulldecent · · Score: 1

    Assume sites want to prevent firesheep, and do not want https everywhere. Does secure cookies fix this?

    Login via HTTPS, get secure cookie ("the token") . Then on each page load, use this token to sign your request.

    This can be done with existing technology, but requires Javascript.

    --

    -- I was raised on the command line, bitch

    1. Re:Secure cookies by Mark+Hood · · Score: 2, Informative

      It can be done, but it's not being done - that's why this happens.

      --
      Liked this comment? Why not buy me something nice
    2. Re:Secure cookies by Anonymous Coward · · Score: 0

      They say that there is a security flag you can set so the browser will not send cookies over a non encrypted link. Never used them myself.

      If you can access those in javascript then you can use a bigmath javascript library to sign a random number or string the server hands out for each request, then send it back to the server as part of same.

      Would noticeably increase back-and-forth traffic and increase time spent signing tokens, because doing security-related math in javascript is slow.

      I donno, give it a shot.

  16. Why not HSTS? by Anonymous Coward · · Score: 1

    The HTTP Strict-Transport-Security (HSTS) header and its predecessors, X-Force-HTTPS and X-Force-TLS, enable HTTP sites to declare that and how they want to be accessed over a secure connection.
    The HSTS header is not recognized by Firefox 3.x. Firefox 4 supports it but without an UI. The extensions ForceTLS and STS UI deal with that, respectively.
    These extensions should be merged with HTTPS Everywhere. It's unreasonable to expect people to manually enter all the sites they use, and it's equally unreasonable to rely on the EFF for maintaining a catalog of the web. We need automatic discovery, and we need manual entries too -- for sites that don't use the header, and to avoid that first insecure connection to retrieve the header.

  17. Windows XP does not support SNI by tepples · · Score: 1

    StartSSL offers free SSL certificates to allow any site to encrypt all of its traffic.

    But you will need a separate IPv4 address for each certificate, which usually means a separate IPv4 address for each domain. Will all Windows XP clients be upgraded to an OS that use Server Name Indication before ARIN runs out of IPv4 addresses? I don't think that's likely.

    1. Re:Windows XP does not support SNI by yuhong · · Score: 1

      To be more precise, XP's built-in crypto library do not support SNI. While IE uses it, I don't think Mozilla uses it, instead they use NSS instead.

    2. Re:Windows XP does not support SNI by tepples · · Score: 1

      Chrome and Safari also use Windows's built-in crypto library. So unless you want to make your HTTPS site exclusive to Firefox and Opera, or until Microsoft finally shuts down the activation server for XP in 2014, each certificate still needs a separate IPv4 address.

    3. Re:Windows XP does not support SNI by Lennie · · Score: 1

      Chrome does support SNI on Windows XP, they still use the same Windows certificate store, but I don't know if they hacked around the Windows library or just use a different library.

      --
      New things are always on the horizon
    4. Re:Windows XP does not support SNI by yuhong · · Score: 1

      Used a different library:
      https://code.google.com/p/chromium/issues/detail?id=43142

    5. Re:Windows XP does not support SNI by Lennie · · Score: 1

      Thanks for letting me know

      --
      New things are always on the horizon
  18. Static vs. dynamic by tepples · · Score: 1

    HTTPS take more processing power to encrypt and decrypt the traffic

    This might be a valid concern for static web pages. But the sorts of web sites with which one would use TLS are more dynamic, to the point where they might be called web applications. How much processing power does HTTPS use compared to what the PHP/Python/Perl/Java app and the database use?

    1. Re:Static vs. dynamic by budgenator · · Score: 1

      it's always in addition to what the PHP/Perl/Python/Java uses. On say slashdot you have multiple servers sliced horizontally so each section can be on a separate server if desired as well as vertically so you have web-servers on the outer layer, Database caches in the middle, and the database itself on the inside; or on other sites you have the web-server and database server all on a host shared by ten or twelve virtual hosts. The load that a slashdot can service probably wouldn't be much of a problem going all https, but a shared host would easily get into crash and burn situations.

      --
      Apocalypse Cancelled, Sorry, No Ticket Refunds
  19. In addition by how much? by tepples · · Score: 1

    it's always in addition to what the PHP/Perl/Python/Java uses.

    But how much addition? Would HTTPS increase the CPU load of a typical PHP blog, forum, or wiki engine by 1%, 10%, 100%, or more?

    1. Re:In addition by how much? by budgenator · · Score: 1

      SSL uses strong cryptographic encryption, which necessitates a lot of number crunching. When you request a webpage via HTTPS, everything (even the images) is encrypted before it is transferred. So increased HTTPS traffic leads to load increases. Why does my webserver have a higher load, now that it serves SSL encrypted traffic?

      All servers will display an increased load how ever

      In my experience, servers that are heavy on dynamic content tend to be impacted less by HTTPS because the time spent encrypting (SSL-overhead) is insignificant compared to content generation time. HTTP vs HTTPS performance

      yet with web 2.0 type stuff with lots of ajax

      Many, very short sessions means that handshaking time will overwhelm any other performance factors. Longer sessions will mean the handshaking cost will be incurred at the start of the session, but subsequent requests will have relatively low overhead.HTTP vs HTTPS performance

      all of the connections are going to kill you. The short answer is 10-20% but YMMV. No idea what happens when you start adding in Google adsense and other third party crap.

      --
      Apocalypse Cancelled, Sorry, No Ticket Refunds
    2. Re:In addition by how much? by Lennie · · Score: 1

      Yes, a higher load, but the load will only be increased by a very, very small marinal number. Just have a look at what the Google study had to say about it.

      With the right extension we could even speed up loading of the webpages:

      http://www.chromium.org/spdy/spdy-whitepaper

      Because HTTP does not currently do multiplexing of multiple streams over the same TCP (or TCP/SSL) connection. The only solution that is has is to open several connections and because we need to use TCP-slowstart it can't utilize the available bandwidth.

      --
      New things are always on the horizon
  20. ipod by religious+freak · · Score: 1

    I need to look this up, but does anyone know how to use this on an unjailbroken ipod, or how about the facebook application on the ipod?

    I know the dangers and concerns, but I still use unencrypted wifi like all those that don't even have a clue. I suppose I'm the worst of all... but I bet I'm not alone. It really is amazing how a system with so many vulnerabilities manages to stay together and grow for decades :-P

    --
    If you can read this... 01110101 01110010 00100000 01100001 00100000 01100111 01100101 01100101 01101011
  21. https://twitter.com almost works... by yuhong · · Score: 1

    https://twitter.com/ almost works, but I sniffed the packets using Wireshark and unfortunately they still make one HTTP request, which because the session cookie is not marked secure is sent insecurely along with it. I remember reading that it was made using XMLHTTPRequest.

    1. Re:https://twitter.com almost works... by yuhong · · Score: 1

      Ah, I think that was from days ago. I just checked today using Wireshark again and they fixed it, which means https://twitter.com/ should be safe now.

  22. RFC 4398 by tepples · · Score: 1

    We would atleast still need something like DNSSEC to validate what is stored in DNS. So that we can store in DNS, not just the A- or AAAA-record, but also which CA is allowed to sign your certificates.

    But by the time you're using DNSSEC, the domain registry is already acting as an ersatz CA by signing the CERT record (RFC 4398) that you have added to your domain. So I agree that DNSSEC is the real answer to TLS PKI.

    1. Re:RFC 4398 by Lennie · · Score: 1

      So far I've not seen anyone implement any specification. This is the only real effort so far:

      1. http://www.imperialviolet.org/2010/08/16/dnssectls.html

      2. Dan Kaminsky released Phreebird which includes Phreeload which is a library on top of OpenSSL to verify certificate fingerprints using DNSSEC and a TXT-record.

      --
      New things are always on the horizon