back to article Time to ditch HTTP – govt malware injection kit thrust into spotlight

A new report form the Toronto-based internet watchdog Citizen Lab has shown cases of governments running network injection attacks that can deliver malware via any HTTP web connection. The dossier looks at two hacking tools created by the Italian firm Hacking Team and the German biz FinFisher that use the injection attack …

  1. Anonymous Coward
    Anonymous Coward

    Missing information

    What systems can it infect? Windows, that's an obvious and easy target. But what about Android, iOS, OS X, Linux?

    Since none of those run the browser with root privileges (plus sandboxed on iOS) it isn't clear how much good that does. Can't p0wn the whole system with only user-level privs, unless it is paired with a privilege escalation bug. Those aren't as easy to come by as back in the old days when so much crap was suid root for no good reason.

    Maybe they can steal an iOS user's browser history, I'm not sure I care too much about that though!

    1. Franklin

      Re: Missing information

      From the sound of it, the hacking device is simply a payload delivery system; it would be up to whoever is deploying it to equip it with the appropriate payload.

      Attacks exist against both Mac OS and Windows targets by exploiting holes in Flash (the Mac DSchanger malware is an example of an attack that targets Mac OS). Presumably, there are attack vectors against Linux as well, and I'm aware of at least one attack against old versions of Android that could presumably be loaded into this device.

    2. Destroy All Monsters Silver badge
      Paris Hilton

      Re: Missing information

      > so much crap was suid root for no good reason.

      When was that? Sounds like a tall tale of Middle Earth.

      1. Anonymous Coward
        Anonymous Coward

        @Destroy All Monsters

        If you can't remember when tons of stuff was suid root for no good reason, you obviously a newbie to Linux/Unix. Because you wouldn't make that statement if you remembered the situation back in the 90s.

    3. diodesign (Written by Reg staff) Silver badge

      Re: Missing information

      "What systems can it infect?"

      You name it, your government can own it.

      C.

      1. Matt Bryant Silver badge
        Facepalm

        Re: diodesign Re: Missing information

        "You name it, your government can own it." If they have a REASON to, not just because you wear tinfoil.

        1. The Dude
          Facepalm

          Re: diodesign Missing information

          ...If they have a REASON...

          Matt... they always have a REASON, we know that. The important question is: do they have a VALID reason?

          1. Matt Bryant Silver badge
            FAIL

            Re: The Dupe Re: diodesign Missing information

            "....do they have a VALID reason?" You seem to have slept through the 9/11 events, the London Tube bombings, the Madrid bombing, and countless other terror events alone. Or maybe you assumed Islamic terror died when bin-bag Laden got his just desserts? You probably missed that even RT, not exactly a fan of The Establishment, is posting articles on a direct and current threat to the UK, one where the security services most definitely do have a very good reason to be watching the coms of such loons: http://rt.com/uk/166128-isis-jihadists-threaten-britain/

            And that's an easy one for you - I wouldn't even try to explain anything more complex like tracking international criminals, agit-prop groups and threats from non-state players. I suggest you stick to small steps for now, build up slowly, and maybe you'll actually reach a state of relative awareness some time this decade.

            1. Anonymous Coward
              Anonymous Coward

              Re: The Dupe diodesign Missing information

              None of that is a VALID reason to spy on EVERYBODY. Stop trolling, even you aren't that dumb.

    4. kwhitefoot

      Re: Missing information

      If it's after information that can be found in the user's files why would it need root privileges? I don't care if the miscreant can own the system if he already owns my data.

      1. Cipher

        Re: Missing information

        Good point, if your data is what they're after root is moot...

    5. Paul

      Re: Missing information

      you don't need to root the user's computer if you can inject HTML into a normal web page and then make use of XSS to make their browser do interesting things and perhaps steal cookies.

      if you're a repressive governement being able to spy on someone's access to twitter or facebook is very useful.

    6. Anonymous Coward
      Anonymous Coward

      Re: Missing information

      "Windows, that's an obvious and easy target. But what about Android, iOS, OS X, Linux?"

      Seeing as both OS-X and enterprise Linux distributions have had far more security vulnerabilities than current Windows versions, the answer would definitely be yes for those two. (OS-X is on over 2,000!)

      Android we already know is utterly insecure, and requires bolt-ons like Knox to even approach the out of the box security of say Blackberry or Windows Phone - and even IOS while well locked down in comparison to Android has had hundreds of previous vulnerabilities.

      1. alain williams Silver badge

        Re: Missing information

        both OS-X and enterprise Linux distributions have had far more security vulnerabilities than current Windows versions

        Can you provide some information to back that claim up please.

  2. Liam2

    SSL is a good thing

    If only it didn't cost so much for hosts.

    1. Christian Berger

      Re: SSL is a good thing

      Well you can always use self signed certificates. They have little security disadvantage over the ones coming from a CA... unless of course you believe ALL the CAs you trust are somehow all trustworthy and totally secure. If one of those is compromised you are back to the security level of self signed certificates.

      1. Anonymous Coward
        Anonymous Coward

        Re: SSL is a good thing

        You can't really use self-signed certificates. Browsers pop up really alarming warnings that would put off most of your traffic.

        1. Truth4u

          Re: SSL is a good thing

          but fine for hosting your own webmail etc. the alarming message might even help keep the idiots out.

        2. tom dial Silver badge

          Re: SSL is a good thing

          "Browsers pop up really alarming warnings" might not be an entirely bad thing. In that case I have an explicit choice whether to accept the risk of connecting rather than the implicit and sometimes incorrect acceptance that goes with trusting the certs distributed with the browser. I still have some security from the encrypted link, and can't see that risk associated with accepting a private cert differs much from that of trusting the browser and the largely unknown CAs that signed certs for anyone who paid them money.

    2. Destroy All Monsters Silver badge
      Pint

      Re: SSL is a good thing

      > If only it didn't cost so much for hosts.

      Oh, I thought CPU-wise. You mean the certificate.

      Well, you can implement certificate-less SSL.

      Or you can get a certificate at Gandi for EUR 12/year ... though they may revoke it at the drop of a hat ... they are french after all, never sure whether they are serving the State or the Customer.

      1. Anonymous Coward
        Anonymous Coward

        Re: SSL is a good thing

        Namecheap have got one for €6.72 right now, and they usually have something in the $10/yr range. It's relatively easy to do, especially if you have cPanel hosting. Generate a server key, buy your certificate and then install it on the server.

        Self-signed is fine for personal use or for a small group who either have enough technical knowhow to know that a self-signed cert isn't the end of the world; or who you can tell in advance "your browser is going to have fits at this point...just ignore it".

        You just can't use it for anything involving random visitors because the chances are that they will never see your site. I'd have SSL on everything just as a courtesy detail if the warnings weren't so dire.

    3. Anonymous Coward
      Anonymous Coward

      Re: SSL is a good thing

      "If only it didn't cost so much for hosts."

      This subject came up when Google announced they were going to start favouring https sites in search results.

      I checked with my ISP - 70 dollars per year per domain IIRC, and significantly more expensive for wildcard ability for subdomains.

      With half a dozen web sites that's ludicrously expensive compared to the 10 dollars a month I pay for the hosting.

      1. Mr Anonymous

        Re: SSL is a good thing

        "I checked with my ISP - 70 dollars per year per domain IIRC, and significantly more expensive for wildcard ability for subdomains." startssl.com class 1 certs are free.

        1. bpfh

          Re: SSL is a good thing

          Startssl class 1 certificates will also pop up browser warnings as it seems they are no longer in any certificate trust list deployed with any browser... I ended up rolling my own.

        2. NullReference Exception

          Re: SSL is a good thing

          StartSSL has recently started to reject requests for Class 1 certs for any website that looks even remotely commercial, claiming that their free product is not intended for commercial use. (They appear to be manually checking sites.) They do have a pay product, but unless you plan to issue multiple certificates for a single domain it's priced higher than most of the competition.

          The ultimate solution here is to distribute certificates via DNSSEC and cut the CA's out of the loop entirely, but that's a long way off. And the domain registrars will probably find some way of charging for it anyway, seeing as how many of them are also in the CA business.

    4. Anonymous Coward
      Anonymous Coward

      Re: SSL is a good thing

      If you want free SSL then a certificate from startssl.com is free and works in pretty much all browsers.

  3. Old Handle

    Then we need a more democratic alternative to https certs. I just don't think it's reasonable to expect everyone to get https set under the current system.

    1. -v(o.o)v-

      DANE is the solution

      In my opinion DANE/TLSA records in DNSSEC signed zones would be the answer.

      Self-sign the cert but put cert thumbprint in DNS - browser verifies the cert from HTTPS matches what is in TLSA. Would also work against dodgy CAs and loading own CA-certs as is done by enterprises using SSL decryption systems.

      Uptake of this has been glacially slow. I do wonder why......

  4. This post has been deleted by its author

  5. Christian Berger

    Well, but in this case HTTPS wouldn't help

    Most governments already run their own CAs which means they can easily issue fake certificates which will be accepted by the browser. So if you already do man in the middle, it's trivial for a government to just intercept that. We already see that in some countries.

    The big problem is the CA system in SSL/TLS. It relies on hundreds of organisations to all be trustworthy. Therefore I'd go for a system like in ssh where you see the fingerprint of the public key of the host and once you've connected to it, your computer will remember it. That way an attacker would have to continuously and reliably do a man in the middle.

    SSL/TLS is only really good against passive attacks, and for that you don't even need the CA system. Perhaps we should make browser display the public key of the host as some kind of graphics. Sure it would just be a pattern of dots or something, but it could be done in a way that's easily recognizable. Or maybe we extend the URL standard in a way to include some public key information. Such longer URLs could then be promoted via QR codes.

    1. Destroy All Monsters Silver badge

      Re: Well, but in this case HTTPS wouldn't help

      So run your own CA.

    2. Long John Brass

      Re: Well, but in this case HTTPS wouldn't help

      Would it?

      If a session is encrypted via a given CA-Chain, will that allow another CA chain into the encrypted stream?

      so..

      EvilGovt CA --> PKI --> TargetSiteCert --> Session

      Other CA --> PKI -- Read SiteCert --> Session

      Don't see how you would be able to insert malware into the Real Site session

    3. Steve Knox

      Re: Well, but in this case HTTPS wouldn't help

      Most governments already run their own CAs which means they can easily issue fake certificates which will be accepted by the browser.

      Only if your browser is configured to trust the government-run CA. If you don't know how to change the CAs your browser will trust, google <your browser> manage certificates.

  6. This post has been deleted by its author

    1. This post has been deleted by its author

      1. Truth4u

        Re: HTTP?S?

        o shit someone will hack in and post rude comments under my name?

        oh wait i already do that myself.

    2. diodesign (Written by Reg staff) Silver badge

      Re: HTTP?S?

      Yes, The Reg doesn't serve over HTTPS. Hopefully, we can change that soon.

      C.

  7. Anonymous Coward
    Big Brother

    Should work over HTTPS too

    Should work over HTTPS too .. ref

  8. P. Lee
    FAIL

    This is why you *don't* want HTTPS

    Use a plain text protocol. Parse and accept only plain text.

    As soon as you add the complexity of encryption, you are relying on someone else to do the job right and you can no longer easily analyse what is going on.

    You only want encryption where you need to keep things secret. Don't add complexity where you don't need it. A CA-signed HTTPS site won't stop injections. Just ask Bluecoat.

    You can combine both systems. Use an ultra-simple plain-text system to pass an encrypted file which you can decrypt offline or on a system which can be wiped. Banks do this all the time to shift transaction records - its PGP files transferred by FTP. You can use horribly insecure FTP because all the authentication and encryption happens elsewhere. You aren't trusting the transport.

    Complexity is an enemy of security.

    However, CA-encryption/authentication might help knock off risks further down the food chain presuming these tools get out. Again, probably the correct response is to simplify the client. Cut out the plugins, use wipe-able systems, block JS etc.

    /goes back to mumbling about the days when ftp was the primary interface used on the internet. My current ftp client is 150kB. That's a whole lot easier to audit than Chromium, Firefox and by a massive long-shot, IE. "Pretty" is causing massive security issues.

    1. Anonymous Coward
      Anonymous Coward

      Re: This is why you *don't* want HTTPS

      Complexity? SSL is hardly complex to implement.

      Things to keep secret:

      Username/Password.

      Authentication Tokens

      Session Tokens

      Online Purchases

      PHI

      PII

      Privacy in General

      ...you get the point.

      Maintaining session state across web farm is more complex than HTTPS, but mechanisms were created. Making sure the proper user remains authenticated to that session, and it not able to be hijacked is more complex than HTTPS, so you implement anti-CSRF countermeasures....which will warp most Web Dev's minds. And speaking of injections.....user provided input. Do we need a post "This is why you *don't* accept any input from the client side"? No, you validate every single piece of user input.....more complex than HTTPS.

      Sure FTP is a lighter weight, less complex protocol, but you shouldn't just encrypt the data.....so add SSL and make it FTPS. Now you have a choice, Explicit (yes) or Implicit (no).....but people still make bad decisions and use implicit. So Explicit it is....now you have a potential issue if you encrypt the command channel and try to perform a transfer or even a directory listing through a firewall....so you have to know about that...Now SSL is making FTP complex. And sure, PGP'ing the data great, but you have to rely on the other side's policies. Do they decrypt upon receipt and leave the data on that FTP server? Maybe, and you have no control of that data after the PUT. .....and why wouldn't you encrypt the logon? No SSL, someone captures the logon, uses it, finds that the data is not no longer encrypted at rest and GET.

      FTP has been around since the 80's, yet 99% of networking and sysadmins open ports 20 and 21 for Active FTP on the server side; because they think port 20 is a destination port. It's a Source Port, so close port 20. 30 years on, and you try to explain that concept, it makes their eyes glaze over.

      Security is not easy, implementing SSL is.

      1. P. Lee

        Re: This is why you *don't* want HTTPS

        SSL maybe easy but the openSSL library people still got it wrong and the library is acknowleged to be a coding nightmare. It might be poor form, but it also suggests complexity in getting it done right.

        Perhaps I should have included a troll icon, buy my point was that web browsers are massive overkill for the simple transfer of information. One way of increasing your security is to decrease your attack surface - smaller, easier to audit code of which an ftp client is a prime example. Pick wget or curl instead if you want, or use netcat and pipe the listener to a file for offline processing.

        If I had some really sensitve things to hide, I wouldn't just rely on SSL if I thought goverment's were involved and I would assume that my ISP had been compromised. If my safety relied on it, I don't think I would rely on a Cisco/Checkpoint or whatever VPN. With all the shenanigins with the NSA, I'd be doing PGP with netcat to a VM, cut and paste the text to another host and wipe the TAILS VM.

        Yes I want an IPS, but do I want to have to give my IPS my SSL keys? No. That leaves me vulnerable to another set of potential bugs. Without the SSL keys, I can't do IPS. I want to see those get and put commands with TCPDUMP. I only want to encrypt the minimum secret data. Encrypting everything all the time makes it difficult to manage and troubleshoot and may leave you open to stats analysis. Plus, you can't cache the data in the middle. That's often a bad thing.

        Super-secrecy may not be common use-case, but the context was government interference. I was merely pointing out that when banks need to move transaction records, they don't rely on transport tunnels and maybe we shouldn't either.

        1. This post has been deleted by its author

    2. Charles 9

      Re: This is why you *don't* want HTTPS

      "/goes back to mumbling about the days when ftp was the primary interface used on the internet. My current ftp client is 150kB. That's a whole lot easier to audit than Chromium, Firefox and by a massive long-shot, IE. "Pretty" is causing massive security issues."

      The issue the article describes, and one that FTP can fall into, as well as SMTP, POP3, NNTP, and just about ANY plaintext protocol, is that a malcontent can MITM the connection and alter the contents in transit. In FTP's case, the file transfers and directory listings can be poisoned. And it would be indistinguishable on your end, meaning you have no way to know you're not REALLY getting the stuff you asked for.

  9. Anonymous Coward
    Anonymous Coward

    Possible solution?

    Public Key HTTP

    The Server could encrypt pages using a user-provided Public Key. Either use a short one included in the URL, or for registered users maybe use a provided much longer key. Data served can then be encrypted using a >4kbit key.

    Each page would be sent with content sent in a random order (e.g. two <div>s wouldn't necessarily be in the same position in two servings of the same page, and <head> need not necessarily precede <body>).

    The tags would then be re-arranged using CSS or a plugin or a custom-written 'secure' browser. This would mean that a page would render correctly- the user need not even be aware of the security.

    Page creators need not normally be too careful either; a parser could convert a 'normal' web-page into one that could be rebuilt (e.g. naming every element so the page can be rebuilt).

    1. Anonymous Coward
      Anonymous Coward

      Re: Possible solution?

      I had been thinking about that myself as an alternative to passwords. Each side generates a keypair for this unique pairing (I call it per-server/per-user). Each side then gives the other the public key. This can happen online for low-security applications, through clandestine post for moderate security, and in person for high security. When a connection is made, some kind of handshake can then be used to match up the user to the server so each side knows which keys to use, then use those to initiate a trusted session. If the session breaks in some way, renegotiate using the same method.

      This would prevent intercepts on the fly and reduce the security issue to keeping the keys secure at each end, which I will admit is hard itself in its own ways (the server end is multi-user, meaning a matter of trust while the client end is potentially low-aptitude, meaning the key management needs to be as simple AND simultaneously as robust as possible--possibly use a physical fob to make an analogue to house keys).

      1. Anonymous Coward
        Anonymous Coward

        Re: Possible solution?

        People should really use that method to encrypt email. Hmmmm.......I wonder why S/MIME hasn't taken off? :)

        The main issue is that you're asking the server to trust a key generated from an untrustworthy source. I know, I know.....NSA, compromised CAs - who can be trusted. Well, certainly not a malware infected PC.

        Also, is that one client key pair for all sites? One for each site? Or session? Generating large keys is CPU, and possibly time intensive. So connecting to the future HTTPS El Reg could take 30 seconds or more just to generate your key pair......user's are not waiting around for that. And outfitting each client with WWW key generation would be a monumental task .... and they'd probably just try to build it into a browser using Java.

    2. Adam 1

      Re: Possible solution?

      >The Server could encrypt pages using a user-provided Public Key.

      Sure could. How do you validate that the server you sent the public key to is the right one? A malicious server could substitute your public key with its own, talk to the real server, decrypt the website, then re encrypt it with your public key and you are none the wiser.

  10. Anonymous Coward
    Anonymous Coward

    Classic Man-In-The-Middle scenario

    I'd suspect any unencrypted traffic to be vulnerable to this. HTTP is an easy attack vector, because browsers are riddled with holes. I would think that you could use other plaintext protocols to cause harm as well... but it may be more sophisticated.

    What a MITM scenario like this is guaranteed to be capable of: reading everything that is not encrypted.

    Man-in-the-middle is always dangerous, and the user cannot do a lot except relying on and applying updates regularly.

    1. Anonymous Coward
      Anonymous Coward

      Re: Classic Man-In-The-Middle scenario

      In this case, HTTP is probably being used simply as the most ubiquitous, but seen more broadly, just about any plaintest TCP session that can transfer binary files can be intercepted to do some nastiness. Imagine FTP binary transfers being poisoned, or rogue attachments made on the fly to SMTP and POP e-mail transfer and NNTP news articles.

  11. This post has been deleted by its author

    1. Anonymous Coward
      Holmes

      Re: So...uh...

      "...why can't I access this url over SSL?"

      Someone beat you to that question, quite a while back in the thread, and received a response from diodesign. I refer you to the Right Honourable Gentleman, etc etc.

  12. Anonymous Coward
    Anonymous Coward

    yes...

    "One way to block this kind of attack is to connect via HTTPS, which encrypts the connection and protects it from tampering – assuming the SSL CA certificates aren't compromised."

    Have you checked the state sponsored CA's your browser trusts by default?

    1. Anonymous Coward
      Anonymous Coward

      Re: yes...

      Prune them out.

  13. Destroy All Monsters Silver badge
    Windows

    In other considerations...

    yum update via https when?

  14. Paul

    buy it? it's free!

    why do you need to buy this technology? it's free for a basic version!

    kudos to these guys

    http://portswigger.net/burp/

    just poison DNS to get the victim to send their http traffic to you, or use IP header rewriting to steal the http traffic. simples!

    1. Anonymous Coward
      Anonymous Coward

      Re: buy it? it's free!

      I love that tool for web app testing. But 1, you have to get the client to trust Burp's cert: Not trivial, especially with Firefox. I.E.? Just take over a domain and publish it with GP. Else, the user will get an error. And if you do get them to trust the cert, and go to Bank of America, for instance....no extended validation, no green bar.

      Now, for fun, if you use GMail, log out of your accounts, setup the proxy on a browser that doesn't trust Burp's cert and try to logon? Ahhhh, no trust, no "Add Exception". You'll see one that permits an exception, but keep on going, and you will not be able to trust the 2nd one, and GMail is out.

      ....and that's the whole point. There are ways to make MITM and other attacks harder to pull off, if the ADMINs and Devs know what they're doing. There are header elements to add that add all sorts of protections (if browser implemented): X-XSS-Protection (for IE), CSP, X-Frame-Options, Cache-Control, Anti-Mime sniffing, specifying the right Mime Type, Anti-CSRF (not a header thing, but.....), and the list goes on. Devs are just too concerned with pretty pictures and font alignment to be bothered.

  15. Anonymous Coward
    Anonymous Coward

    Cheaper than HTTPS?

    Encrypting all traffic is costly, it breaks web caches and for public data (like the youtube example) is overkill. After all, there is no need to hide the content of a harmless cat video, just protect it from tampering.

    We need to be able to digitally sign web pages, or anything transmitted for that matter, so if it is altered mid-stream the browser can tell. Signed, static pages are then identical for all visitors so caching is not broken. The extra workload for servers is minimal.

    Of course this doesn't protect against a true MITM attack, but then again nothing really does. A well funded spook with a CA in his pocket can impersonate anything.

    1. Anonymous Coward
      Anonymous Coward

      Re: Cheaper than HTTPS?

      When a page is altered the attacker can strip out the signature too then it would look like any normal page. It would take years before signing is common enough for browsers to start requiring it and marking 'normal' pages as dangerous.

      1. Anonymous Coward
        Anonymous Coward

        Re: Cheaper than HTTPS?

        Not if the browser is expecting to see a signature… Current HTTP/TLS implementations do support using HTTPS with a NULL cipher, so it's in theory, possible.

        The trick would be telling the server when to serve up a page using a strong cipher, and when to serve up a page with the NULL "cipher". The browser will see https:// in the URL and begin TLS negotiation, so filtering out the signature there isn't going to work.

        Sure your private email text might warrant encryption (the provider won't know how sensitive it is before they send it to you) but the JavaScript, stylesheets and logos: cryptographic verification should be good enough.

        This still leaves the issue of trusting the TLS certificate in the first place… sure you could embed a fingerprint in DNS, but crims can poison that too.

    2. Anonymous Coward
      Anonymous Coward

      Re: Cheaper than HTTPS?

      I just thought of a partial solution. For static content only simply put a SHA value in the URL fragment. The fragment would need to follow a predefined format so browsers know what it is and means. The returning file is hashed and compared, if it differs then reject it. For ancillaries such as JS and SWF (both common attack vectors) this significantly limits damage. For destination addresses, the HTML pages themselves, then hashes are carried along with URLs in bookmarks and search engines. And the best part is no extra traffic is transmitted back to the server and existing proxies do nothing different and caching strategies are preserved.

      1. Anonymous Coward
        Anonymous Coward

        Re: Cheaper than HTTPS?

        I just thought of a partial solution. For static content only simply put a SHA value in the URL fragment. The fragment would need to follow a predefined format so browsers know what it is and means. The returning file is hashed and compared, if it differs then reject it.

        Yeeessss, but that SHA value will need to be followed by a digital signature of it. Any old goose can feed their modified page through sha1sum (or whatever tool you use) and fill in that value with their own replacement.

        I thought of something similar over the weekend, but I came to the realisation that it will only work for fairly small files, as the client has to receive the entire file before it can begin verification. This isn't a problem for small things like logos, stylesheets and JavaScript. May not be a problem for the page content either.

        However, for any streamed content it's a no-go, and you can forget being able to view a photo before it's fully downloaded.

    3. Anonymous Coward
      Anonymous Coward

      Re: Cheaper than HTTPS?

      YES "We need to be able to digitally sign web pages"

      We're in a full information-war at present, with gchq training hundreds of advanced script kiddies to run JTRIG manipulators; once Scotland "votes" either 'YES' or 'NO' next month - then these propaganda workstations will be freed-up to screw-up something else in our developing online society. We need digitally signed web-pages, and we need them now!

      the chrome/ff extensions: https everywhere; certificate patrol; user agent switcher (set to iPad); Flagfox are vaguely helpful, similar to an aspirin-a-day...

      so when & how can we launch apt-get update --bbc.news.com --RT.ru --Telegraph.co.uk

      requesting WWW keys from hkp server subkeys.pgp.net gpg: WWW keys: public key "BBC Extras websites Automatic Signing Key <ftpmaster@bbc.com>", public key "Russia Today Extras websites Automatic Signing Key <ftpmaster@RT.ru>",public key "Telegraph Extras websites Automatic Signing Key <ftpmaster@Telegraph.co.uk>" imported gpg: 3 trusted keys found from ALL OS'es/Browsers?

  16. Anonymous Coward
    Anonymous Coward

    > Human Rights Watch notes that Turkmenistan is "one of the world’s most repressive countries," and that Oman has a long record of spying on and harassing citizens who wish to reform the state's absolute monarchy.

    And both Turkmenistan and Oman pale in comparison with US/UK, but let's not mention that.

  17. razorfishsl

    Most of the Chinese Telicom providers for ADSL do this when the line connects.

    Initially they try a DHCP redirect for whatever site you want to look at.

  18. awood_this_or_that

    Come on El Reg.....

    Not even SSL on account creation???? I guess I should say "thanks" for the 302 on post?

    POST /register/ HTTP/1.1

    Host: account.theregister.co.uk

    Referer: http://account.theregister.co.uk/register/?product=comment

    product=comment&text_only=0&forename=a&surname=wood&handle=awood_this_or_that&email=free.dnloads%40gmail.com&password=WhyNoHTTPS&confirm_password=WhyNoHTTPS&country=us&job_function=&other_job_function=Security+Engineer&job_sector=xxxx&other_job_sector=&employee_count=1001+to+2000&it_spending=I+make+recommendations+on+major+IT+spending&submit=Sign+Up

    Nmap scan report for account.theregister.co.uk (92.52.96.116)

    Host is up.

    PORT STATE SERVICE

    443/tcp filtered https

    .....don't try, pwd already changed.

    1. diodesign (Written by Reg staff) Silver badge

      Re: Come on El Reg.....

      "Not even SSL on account creation????"

      Yes, we know. Hopefully this will change.

      C.

  19. Anonymous Coward
    Joke

    To steal politely from Wil Wheaton..

    I'm posting to The Register over a Tor Connection in a LiveCD booted in Virtualbox from a security distro running entirely in memory on a laptop flashed with FreeBIOS in a TEMPEST shielded room in that abandoned warehouse from 'Enemy of the State'... and I have a cat, so I don't NEED videos. Your move, GCHQ, your move.

    1. Anonymous Coward
      Anonymous Coward

      Re: To steal politely from Wil Wheaton..

      You already lost. GCHQ knew about that warehouse well ahead of you. They bugged that room on the inside eight ways to Sunday and hid all of them so well they probably couldn't even be found by an X-ray. Plus they bugged the TOR endpoint you're using as the other end of the line.

      1. Destroy All Monsters Silver badge
        Gimp

        Re: To steal politely from Wil Wheaton..

        The cat.

        The cat actually controls you.

        1. Solmyr ibn Wali Barad

          stolen shamelessly from a haiku site

          guess what i found out

          my cat rules the universe

          that explains a lot

      2. Anonymous Coward
        Anonymous Coward

        Re: To steal politely from Wil Wheaton..

        "You already lost. GCHQ knew about that warehouse well ahead of you. They bugged that room on the inside eight ways to Sunday and hid all of them so well they probably couldn't even be found by an X-ray. Plus they bugged the TOR endpoint you're using as the other end of the line."

        Time for a slow retreat, into an igloo shaped dwelling constructed entirely of tin foil. Perhaps a entire fresh mackerel, it's tail tied to the trigger for a 1-tonne weight with 'ACME' written on the side for the cat?

  20. Anonymous Coward
    Anonymous Coward

    Unless you're a crim...

    ...you have nothing to worry about.

    1. Destroy All Monsters Silver badge
      Angel

      Re: Unless you're a crim...

      It's easy to detect crims: It's the ones who worry!

      The rest are taking their described daily dose of SOMA. 0.4g every morning. And take care boys and girls: Only read websites approved by the psychopathic mavens of interior and foreign policy!

  21. Mookster
    Facepalm

    http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

  22. BasevaInc

    How about SHHTP/CHTTP - Signed HTTP or Checksum HTTP

    The server generates a signed version of the response returns the checksum in the header and its the browser responsibility to signed the plain text response and compare checksums, checksums failed then prompt the user if they wish to load the content!

  23. This post has been deleted by its author

  24. Tom 13

    Re: assuming the SSL CA certificates aren't compromised.

    When the people doing the hacking are state actors at the Five Eyes level, that looks like an awfully big assumption to me. In which case switching to HTTPS only creates a false sense of security. Switching to HTTPS is probably a good idea for non-state actor malware, but I doubt it's going to help in this case.

  25. tom dial Silver badge

    I wonder ...

    ... how many people/websites actually need or benefit from the kind of security being discussed here. The articles on the Register or similar sites are fairly public information that I do not think is likely to implicate me in anything interesting to spy agencies. Comments I post are meant to be read by anyone who cares to and I try to edit them accordingly, mainly to attempt clarity and avoid being offensive. I expect that is true for most of those who read and post on this site. I never have changed comments to avoid the interest of any government agency, although I do not name the one that employed me and avoid describing in detail their information assurance procedures, but anyone seriously interested probably could find out with moderate difficulty at most.

    Account creation over HTTP is a bit offputting, but I knew that going in and provided a password that I do not use for anything associated with data I wish to keep private. I sort of hope it is salted and hashed, and that TheRegister takes reasonable precautions to secure it and the associated account data, but there isn't any correct information there that I care much about keeping private.

    HTTPS certainly is warranted for more important things like online purchasing or bank access. For the most important ones I really would prefer that the identification and authentication in both directions be based on something like hand-to-hand direct exchange of public keys to automated acceptance of certificates signed by one of dozens of CAs about which I know, in most cases, next to nothing.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like