Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Internet of Compromised Things

Posted by Soulskill on from the points-of-failure dept.

An anonymous reader writes: Jeff Atwood has a post about a security threat that's becoming more prevalent every day: spreading malware through a compromised router. "Router malware is the ultimate man-in-the-middle attack. For all meaningful traffic sent through a compromised router that isn't HTTPS encrypted, it is 100% game over." He links to a thorough technical analysis of how even HTTPS encrypted traffic can be subverted. Atwood provides a list of suggestions for keeping your router safe that probably won't be any surprise to people reading this site, and he further recommends only browsing on an unknown router if encryption is available. What I'm curious about are the long-term implications — is there a way forward to re-establish trust in our router infrastructure? What can the open source community do to speed this along?

62 comments

  1. Don't routers already run BSD? by Anonymous Coward · · Score: -1

    Hey lookit, it's open source. And you can't see the source. Because freedom!

    1. Re: Don't routers already run BSD? by Anonymous Coward · · Score: 1

      Nearly all home routers run Linux, genius.

    2. Re:Don't routers already run BSD? by TWX · · Score: 5, Interesting

      Mine runs Linux, compiled for MIPS. It's actually going to be replaced soon anyway so I haven't bothered to do much with it.

      Either way, the average person is only going to use the web interface or the software that the manufacturer provided that runs on the computer, if any. They won't be in position to fix anything that's broken if the manufacturer does not provide either an automatic means or a simple means to do so.

      I think it'll eventually come down to a regulatory issue. Tech companies and those companies that use consumer-facing electronics (like car companies and their infotainment and body-control computers) have proven that they're not interested in maintaining their arguably defective products. Don't mince words, bugs are defects. Companies need to be taken to task over both this and over the increasingly rapid discontinuation of support (like factory-shipped apps on cell phones that stop working and can't be updated because new versions require OS updates that aren't provided) such that companies end up with mandatory windows of support until the last product ships, where all bugs and changes in communications protocols and services are maintained, such that devices that consumers have paid good money for actually last as long as their pricetags indicate that they should. For smartphones I think that window should be five years. For things line broadband routers, it should be at least five years, and I'd argue that it's not unreasonable to demand closer to a decade. For cars, where the average age of cars on the road is now something like twelve or thirteen years, it should be at least a decade for basic feature maintenance and probably another ten years for critical bugs that compromise the security of the vehicle's systems, like these easily unlocked cars we're hearing about.

      Yeah, it sucks to have to maintain old code, but I'm very tired of having to pay for defective products whose features begin to stop working when the companies that wrote those features decide to change directions.

      --
      Do not look into laser with remaining eye.
    3. Re:Don't routers already run BSD? by Anonymous Coward · · Score: 1

      Yeah, it sucks to have to maintain old code, but I'm very tired of having to pay for defective products whose features begin to stop working when the companies that wrote those features decide to change directions.

      So the solution is to mandate by law a minimum support period?

    4. Re:Don't routers already run BSD? by Anonymous Coward · · Score: 0

      Manufacturers should have to support smart phones for five years? What have you been smoking, buddy? And can you pass me some? The hardware itself (screen, casing, battery, etc.) of most phones does not last 5 years - why should the software?

      How about doing it differently? Let's say that the manufacturer warrants - right on the box - the minimum time after retail purchase (not after e-bay or the like) that the device will be patched and kept up to date. It might say something like "latest operating system available for device - 16 months. Security fixes available for 36 months" or something like that. Users then choose which device they want based on all the normal factors PLUS how long the device is supported.

    5. Re:Don't routers already run BSD? by TWX · · Score: 2

      Manufacturers should have to support smart phones for five years? What have you been smoking, buddy? And can you pass me some? The hardware itself (screen, casing, battery, etc.) of most phones does not last 5 years - why should the software?

      My phone is a Samsung Galaxy SII. I bought it when it was newly launched. It is now four years old. My previous phone was a T-Mobile G1, also sold as the HTC Dream, the first retail Android phone, which I also bought when it was newly launched. I still have it and it actually still works, but we replaced it in part because of application problems from being limited to Android 2.3.

      Just because you replace your technology frequently doesn't mean that the rest of us do. Frankly I'd rather spend my money on other pursuits rather than re-buying the same theoretically-durable goods all of the time.

      --
      Do not look into laser with remaining eye.
    6. Re:Don't routers already run BSD? by fahrbot-bot · · Score: 1

      Just because you replace your technology frequently doesn't mean that the rest of us do. Frankly I'd rather spend my money on other pursuits rather than re-buying the same theoretically-durable goods all of the time.

      Agreed. My previous cell phone was a Qualcomm QCP-1900 I bought in 1998 for $200. It was one of the first all-digital phones. It only made voice calls, which is all I needed. I had to get a new phone last month because nTelos (originally PrimeCo in my area) sold their spectrum to Sprint in my area and, for some reason, my phone would no longer work on the network.

      Yes, I arguably got my monies worth from the phone, but it *still* worked just fine - grrr..

      Just to note: I switched to Ting and got a Kyocera Hydo Vibe. Perhaps not a standout phone, but it's got some nice features and is not a wallet breaker. I went with a smartphone instead of flip to give me options... App plug: NextRadio works great on my phone - uses built-in FM tuner for live, OTA (non-streamed) radio using little/no data (enhance/basic interface).

      --
      It must have been something you assimilated. . . .
    7. Re:Don't routers already run BSD? by TWX · · Score: 1

      Heh. My wife had one of the last Analog cell phones, they started implementing a surcharge if she continued using it instead of replacing it with a digital phone. She ended up with a Samsung bar phone, I think an X820, but it's been awhile so I can't remember for sure.

      --
      Do not look into laser with remaining eye.
    8. Re:Don't routers already run BSD? by TWX · · Score: 1

      If the vendors won't do it without it, yes.

      --
      Do not look into laser with remaining eye.
    9. Re:Don't routers already run BSD? by __aaclcg7560 · · Score: 1

      My sister-in-law had an analog phone with a $10 per month service plan for nearly ten years. One day the phone slipped out of her pocket into the toilet bowl and the toilet automatically flushed when she got up. Bye-bye, analog phone. Hello, digital phone with $50/month service plan. Karma!

    10. Re: Don't routers already run BSD? by Anonymous Coward · · Score: 0

      My iPhone 3GS is still in use. Not sure exactly how old, but it's definitely pushing 5 years.

  2. What if the malware is baked in when you buy it? by Anonymous Coward · · Score: 0

    So let's say you're on a watch list. You use your credit card in your name to buy a router. Well since you're on a watch list, that router gets pre-loaded with malware before it's even shipped to you, because you need to be watched! Good luck determining a known-good state of your router, you terrorist, you.

  3. trust consumer grade routers? ha! by Gravis+Zero · · Score: 1

    if you want to trust a router, you better be sure there is a vested interest in it being secure. new consumer grade routers come out as often as car models and the firmware is common crap that has half-assed security in the name of features.

    i wouldn't trust a router without it being open source and open hardware down to the ICs. so... is anyone making a RISC V based router?

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:trust consumer grade routers? ha! by Anonymous Coward · · Score: 1

      Well, there's this, but it's probably not open enough for you, and almost certainly tries to do too much at once, but it's a nice OpenWRT platform.

  4. Re:What if the malware is baked in when you buy it by Zontar+The+Mindless · · Score: 2, Insightful

    Or you could, you know, go to an ATM, withdraw some cash, then walk into $shop and buy one there, using the cash...

    --
    Il n'y a pas de Planet B.
  5. Trusted Network Fallacy by Anonymous Coward · · Score: 4, Insightful

    The people who designed the internet had the right idea: Dumb network, intelligent edge. Perimeter security and trusted networks are dead ends. Communication is from endpoint to endpoint. The network shouldn't even matter. You might be running IP over avian carriers if that's what you need to do to get a connection. But if you need to trust the network between the endpoints, you're doing it wrong. Even if you could trust your own router, do you trust the ten or more routers behind it? Ubiquitous encryption and authentication with IPSec is possible with DNSSEC supplying the keys.

    1. Re:Trusted Network Fallacy by Anonymous Coward · · Score: 4, Interesting

      I think you still have to trust some aspects of the network. Sure, DNSSEC can provide some protection, but what if your ISP's DNS server is compromised to provide bad information? I suppose you could verify it against other servers. Can you trust that the routers your packets pass through are properly routing your traffic to the IP you want it to reach? If done right, compromising these things could be almost invisible to a lot of users. I think you have to trust certain aspects of the network, though you should use encryption to protect against MITM attacks. I think you can avoid many types of exploits, but you have to trust something in order for the internet to function. The idea of using HTTPS is a step in the right direction, except that CAs can't be trusted and the biggest one has a horrible record of security. Add to it that most users are ignorant of HTTPS and many applications don't reveal the protocol to the user and you have a problem. Can you trust that mobile apps and a lot of other software that doesn't explicitly reveal its protocols to the user makes use of encryption? Sure, you could sniff the packets, but who does that? I just don't think you can entirely remove trust from the equation, though we can do a lot better than we do now.

    2. Re:Trusted Network Fallacy by Anonymous Coward · · Score: 2, Insightful

      what if your ISP's DNS server is compromised to provide bad information?

      That's why you need to use DNSSEC, and by use I mean verify that you got authentic data, which DNSSEC lets you do.

    3. Re:Trusted Network Fallacy by Anonymous Coward · · Score: 0

      You are still putting your trust in a third party. DNSSEC doesn't help there. What you need is a method to verify with the endpoint that they are who they claim to be.
      Any method that requires that a government agency or other "official" organization certifies the endpoint is compromised by design. (Unless you trust all governments and commercial interest groups.)

    4. Re:Trusted Network Fallacy by Anonymous Coward · · Score: 1

      You have to trust someone else if you don't already have a secure channel to all other communication endpoints. You're correct in observing that key management is a critical aspect in cryptographic systems, and that government actors are not automatically trustworthy. You are wrong though to assume that you have to trust all governments and commercial interest groups. DNSSEC does not work like SSL, where any CA can issue certificates for any domain. With DNSSEC you only depend on the delegation path to the domain whose key you need to authenticate. The DNSSEC root can be secured against malicious actions by a single government. You can even have a separate root operated by an organization you trust. The root zone is small and doesn't change very much. You could regularly print it in a newspaper, for example. Which top-level domain you use however makes a big difference regarding the trust that your communication partners can have in the authenticity of your keys. Choosing a top level domain by the length and sound of its name is like choosing a car by its color. With a little engineering, it should also be possible to have keys signed by two or more very different delegation paths, so that for example the US government would have to collude with the Russian government to be able to subvert your key.

      Anyway, the important part is that none of that is a network security thing. You trust (relatively few) organizations to maintain the integrity of their signing keys, with each organizations facing significant blowback for violations of that trust, which are easily uncovered. The network can be teeming with malware: As long as the keys are not compromised and the signatures check out, you're fine.

    5. Re:Trusted Network Fallacy by TWX · · Score: 0

      The people who designed the internet had the right idea: Dumb network, intelligent edge.

      No they didn't. There was no default encryption. There was no built-in means to confirm that one was speaking to the host one thought one was speaking to. There was no method in the protocols to detect MIM attacks. Basic protocols require one to be honest about one's identity (like SMTP) and have only relatively recent bandaid attempts to mitigate the disaster that is their implementation. The original Internet was all telnet and UUCP and FTP and SMTP and POP3 and password flying in plain-text all over the place with the first hint of real security, and that mindset is still a problem today.

      --
      Do not look into laser with remaining eye.
    6. Re:Trusted Network Fallacy by Anonymous Coward · · Score: 0

      "Dumb network, intelligent edge" was the right idea. None of the points you made even challenge it:

      There was no default encryption. There wouldn't have been any if they had chosen to put more functionality in intermediary nodes.
      There was no built-in means to confirm that one was speaking to the host one thought one was speaking to. If they had built that into the network, we'd still be relying on our ISPs' honesty, like we are today.
      There was no method in the protocols to detect MIM attacks. And if that job had been assigned to the network, it would be easily subverted, and we would still have to fix it with end-to-end authentication.
      Basic protocols require one to be honest about one's identity (like SMTP) and have only relatively recent bandaid attempts to mitigate the disaster that is their implementation. Luckily we can fix those protocols, because they are not baked into the infrastructure of the net, as it's designed to be a dumb network.
      The original Internet was all telnet and UUCP and FTP and SMTP and POP3 and password flying in plain-text all over the place with the first hint of real security and again, we don't have to keep using these protocols, because they're not part of the network design. We can have more intelligent end-to-end communication because the intelligence is in the endpoints, not the network.

  6. The entire friggin' internet is compromised by Rosco+P.+Coltrane · · Score: 3, Informative

    Nevermind your own dinky router: any traffic you send on the internet is exploited by greedy "big data" companies and rogue 1984-style government agency. And encryption doesn't stop them from watching what you do...

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
    1. Re:The entire friggin' internet is compromised by Anonymous Coward · · Score: 2, Interesting

      This is unfortunately the ugly reality: the internet as we knew it is dead. What many dreamed would be an empowering tool for the masses became the ultimate instrument of power and control for the Ruling Elite. We can't even leave it because all services are being brought online and online only. We have been enslaved and there's nothing we can do. In the end, I almost think the Ruling Elite deserves its great victory: they have been most astute and far-seeing in their acting. It's the culmination of a 20-year long plan. They let us thought we were on the verge of the ultimate revolution and all the time we were shackling ourselves. Maybe there's a reason they should rule. :(

    2. Re:The entire friggin' internet is compromised by Anonymous Coward · · Score: 0

      But it helps to keep the outright hacker/cybercriminal/dickfacejerk out of your traffic a bit yes? In that case it's worth it. Just because it doesn't give you 100% protection doesn't mean you should settle for 0.

    3. Re:The entire friggin' internet is compromised by rmdingler · · Score: 3, Insightful

      This is unfortunately the ugly reality: the internet as we knew it is dead. What many dreamed would be an empowering tool for the masses became the ultimate instrument of power and control for the Ruling Elite.

      To be fair, it's actually a little bit of both.

      Having access to all the compiled knowledge of mankind is empowering for any and every person with internet access, as is being essentially free to contact nearly every other Worldly citizen via the web. The ability to monitor an individual's access to that information is maddeningly power grubbing for the government's surveillance state.

      Being realistic, if it was not advantageous to the ruling elite, would they let us keep it?

      --
      Happiness in intelligent people is the rarest thing I know.

      Ernest Hemingway

    4. Re:The entire friggin' internet is compromised by SuricouRaven · · Score: 1

      No, but it can make watching you sufficiently expensive and impractical as to render it impossible on a non-targetted basis.

      SSL interception is possible, but if any ISP or intelligence service does it on a large scale it will inevitably be noticed.

    5. Re:The entire friggin' internet is compromised by mcrbids · · Score: 2

      I wish this weren't modded up. Really, I do.

      "any traffic" implies "all traffic" and it's simply wrong that "big data" is somehow exploiting, for example, the OpenVPN traffic between my laptop and my home mini server, nor are they making use of anything going on over SSH.

      And encryption doesn't stop them from watching what you do...

      And this is just silly. Of course it does! It is *not* a perfect tool, but it is a damned good one, the engineers did their job. As with any defensive/offensive technique, there are ways to mitigate it, and there are ways to bolster against those mitigations.

      It's plainly obvious from the Snowden leaks that the NSA commonly seeks the private keys of common sites. This strongly implies that the root of the CA fortress is relatively secure - otherwise they wouldn't care. And in light of the Snowden leaks, SSL is being scrutinized, and the holes filled in. OpenSSL finally has a budget!

      Security is a process, not a product. Don't forget that!

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    6. Re:The entire friggin' internet is compromised by tlhIngan · · Score: 1

      What many dreamed would be an empowering tool for the masses became the ultimate instrument of power and control for the Ruling Elite.

      In what way has it ever been about empowering the masses?

      Remember, freedom of the press belongs to those who own the presses. LIkewise, freedom on the internet belongs to those who own the internet - in this case, corporations who sponsor the backbones and who connect our homes with it.

      Always been the case. As long as someone big and power owns a part of it, they control it.

      The closest anyone's come to "freedom" would be the old BBS networks - where all it took was a phone line and a computer. And at night, those computers would exchange information wi th each other. In fact, in places where the internet is heavily censored, FidoNet remains a bastion of freedom because the governments don't monitor the phone lines as strongly as they monitor the internet. Plus, those links constantly change at a furious pace, so what was two nodes transferring data can be a half dozen between borders. And because your email may be randomly routed, you have to monitor all the links.

  7. Security is for cows. by Anonymous Coward · · Score: -1

    You are all cows. Cows say moo. MOOOOOO! MOOOOOOO! Moo cows MOOOOOOO! Moo say the cows. YOU COWS!!

  8. Re:What if the malware is baked in when you buy it by SuricouRaven · · Score: 2

    You can for ADSL routers. Cable service routers usually combine modem and router into one box, and DOCSIS authenticates this device with the other end of the network cryptographically - even if you wanted to replace it, you couldn't. If you check the fine print you'll usually find that the modem-router is the property of the cable company and serves as the demarcation point.

  9. Re:What if the malware is baked in when you buy it by Anonymous Coward · · Score: 1

    Although US cable companies will happily lease you a modem for an exorbitant monthly fee, you're not tied to using their modem or router. The only hardware I absolutely have to use from the cable company for my setup is a cable box, for TV. I also leave a device for switched digital video, and a cablecard. I don't have to use the last two. Maybe things are different where you are, or with a different provider, but being able to bring your own modem and router is pretty standard here in the US. Whether those devices don't have malware included, intentionally or otherwise, in their firmware is a different discussion. But as long as your router and modem are compatible with their network, US cable companies don't mind you using your own hardware instead of theirs. In fact, it generally saves you money in the long run by not paying their monthly fees.

  10. real security isn't practical by Anonymous Coward · · Score: 0

    I don't think real security is practical. Consider the following:

    1) What if routers or DNS servers at a major ISP are compromised to redirect traffic intended for legitimate websites to fake versions of the same site. Instead of relying on traditional phishing attacks, which a careful user can spot, this is nearly invisible to any user.

    2) Perhaps observant users will notice that these connections aren't authenticated with HTTPS if they're prompted to login. However, a lot of this relies on certificates issued by companies like Verisign. And Verisign has an awful history of security with numerous serious breaches.

    Short of having sites prove their identity to you (a reverse multi-factor authentication scheme), I don't think there's a good way around this. However, it's impractical to do this, especially for every site you might visit. It might work for banks to stop phishing, but it simply isn't practical for every site you visit. I think the reason this type of attack hasn't occurred on a large scale yet is because it's a lot easier to fool unsuspecting victims with phishing emails.

    For those who say you shouldn't trust the internet, I think you have to trust it to some degree. Perhaps you shouldn't trust that your traffic isn't being monitored. But you almost have to trust that it's being routed correctly.

  11. Could a meme turn me gay?! by Anonymous Coward · · Score: -1

    Wetware malware could give me a GAYNIGGER fetish! I'd better get my shapely ass off the Internet before rigid black cock looks appealing to suck on.

  12. Re:What if the malware is baked in when you buy it by Runaway1956 · · Score: 2

    http://myopenrouter.com/

    If you're interested in security, you'll buy a router which you can flash and program to your own liking.

    I don't know how to counter a custom spying chip that might be embedded on your router's board, but defeating software is pretty damned easy.

    --
    "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
  13. HTTPS is not the only encryption by Cigaes · · Score: 3, Insightful

    The first thing I notice about that article is that it help spreading the misconception that HTTP is the only use of Internet and HTTPS the only encryption scheme. I must say, I feel much safer knowing my SSH sessions are not HTTPS-encrypted, because the certification mechanism is completely broken.

    1. Re:HTTPS is not the only encryption by msobkow · · Score: 2

      TLS is no more broken than SSL, and can be used by HTTPS sessions. If anything, SSL is the older and less reliable protocol, and that is what SSH is built over. So is sftp.

      Regardless of whether you are using TLS or SSL, you are relying on the same public key infrastructure system to identify hosts. So I don't know where you get the idea that SSH is "more secure."

      --
      I do not fail; I succeed at finding out what does not work.
    2. Re: HTTPS is not the only encryption by Anonymous Coward · · Score: 1

      SSH does not use SSL and also has no CA (this is what parent talked about).

    3. Re:HTTPS is not the only encryption by Cigaes · · Score: 1

      TLS is the name for later evolutions of the SSL protocol, but as someone else already noted, I was talking about SSH, not SSL.

    4. Re:HTTPS is not the only encryption by swillden · · Score: 1

      The first thing I notice about that article is that it help spreading the misconception that HTTP is the only use of Internet and HTTPS the only encryption scheme. I must say, I feel much safer knowing my SSH sessions are not HTTPS-encrypted, because the certification mechanism is completely broken.

      The HTTPS certification infrastructure has problems, but to say that SSH is better because it doesn't have one at all is rather bizarre. If you'd like exactly the same sort of security from HTTPS that you get from SSH you can verify HTTPS certificate IDs manually, and you can install a browser extension that warns you when they change.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:HTTPS is not the only encryption by Cigaes · · Score: 1

      Sorry, but it does not work. People who manage SSH servers know what a private key is, they treat it as a precious file and keep it when, for example, restoring from a hardware failure. Only when the key is compromised do they change it. If they are really serious about it will even distribute the fingerprint along with other necessary information when opening new accounts. You can verify it carefully, and then it is once and for all in the known_hosts file.

      People who manage HTTPS sites, on the other hand, do not know what a private key is, or act like it. Websites change their keys every other day, have dozens of AJAX servers all with different keys, and sometimes even have different keys for different servers acting as round-robin for the same domain name. Checking all of them manually utterly impractical. And browsers do not even have an interface to manage that easily. Worse: IIRC, browsers do not even have an interface to check certificates for AJAX requests, they just fail silently.

    6. Re: HTTPS is not the only encryption by msobkow · · Score: 1

      With no CA, how can you claim that it's "more secure"? You have no way of knowing the certificate was actually issued for the server you connect to if that's the case!

      Here I'd always thought people were just using self-signed certs, but if there is no CA, it's not even that secure.

      --
      I do not fail; I succeed at finding out what does not work.
    7. Re:HTTPS is not the only encryption by swillden · · Score: 1

      So, essentially, your argument is that the SSH method does not scale. I agree.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    8. Re:HTTPS is not the only encryption by Cigaes · · Score: 1

      Absolutely not. My argument is that the TLS authentication architecture is broken beyond repair.

      The SSH authentication system does not scale, but it is sound, and it could be made to scale without changing the base principle. The TLS authentication can not be repaired without changing it from the core.

    9. Re:HTTPS is not the only encryption by swillden · · Score: 1

      Absolutely not. My argument is that the TLS authentication architecture is broken beyond repair.

      The SSH authentication system does not scale, but it is sound, and it could be made to scale without changing the base principle. The TLS authentication can not be repaired without changing it from the core.

      There is no SSH authentication "system". It's purely manual. How could it scale for use by billions of people who know nothing about security and are more than happy to click "OK" just to get that annoying dialog out of the way? Particularly without forcing far-reaching changes in the rest of the web infrastructure.

      Also, I disagree that TLS' authentication architecture is broken beyond repair, for two reasons. First, in actual practice for the vast majority of uses, it's not broken at all. Given the scope and scale of TLS usage, actual breaks due to CA system failures are vanishingly rare, and mostly confined to nation-state actors who, frankly, are extremely hard to defeat regardless of the design.

      Second, we have some excellent proposals as to how we can shore up the few issues that have cropped up. Google's Certificate Transparency project, plus more care by browser makers of whose signing certs they package will address the worst of the problems. If that's not enough, we could stand up something like Marlinspike's Convergence... not as a replacement for the CA infrastructure but as an additional, stand-beside layer of protection.

      Unless you can define some architecture that both scales as well as CA-based PKI and has none of the flaws of CA-based PKI, and doesn't require retooling apparently-unrelated parts of the web, then we're clearly better off adding more layers of protection on the CA system instead of throwing it out and starting over. Actually, since whatever you come up with will have its own, as-yet-unknown flaws, I'd say we're better off even if you could articulate such a system.

      Finally, I think SSH authentication is overrated. How often do you actually check your SSH key fingerprints? Unless you're very, very different from most users of SSH, you log in, get a message about a key, think for half a second "Is this actually the first time I've connected to this computer? I think so..." and hit 'y'. And if you actually are that much more conscientious than the vast majority of SSH users, good for you, but that just further shows you're not the right person to decide how the world should authenticate.

      In practice, even when presented with the nasty message caused when the server's key changes, few users dig into the issue unless they have reason to know that the key should not have changed. Instead, they delete the offending key from their authorized_hosts file and try again. And we're talking about sysadmins who are nominally competent and security-conscious.

      Tell me how that's going to work with your grandma. Scalability issues aside, how is she going to react when a key changes? At best browsers, etc., will make bypassing the warning message hard to do, freaking users out and causing system administrators to avoid rotating keys (a bad thing). In reality it'll be some equivalent of "delete that bad key and get the new one."

      SSH authentication is okay for its intended audience. Not ideal, but okay. But it would result if far less security than the current system if applied to the rest of the world.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    10. Re:HTTPS is not the only encryption by Cigaes · · Score: 1

      Once again, I did not propose to replace the broken CA system by anything resembling .ssh/known_hosts, that makes more than half your long messages irrelevant.

    11. Re:HTTPS is not the only encryption by Anubis+IV · · Score: 1

      I'm seeing a few misconceptions in what you've said here as well as in your subsequent posts in these threads, so I hope you'll pardon the upcoming car analogies in response to this sentence:

      I feel much safer knowing my SSH sessions are not HTTPS-encrypted, because the certification mechanism is completely broken.

      To me, that reads like:

      I feel safer knowing my Newegg packages are not Amazon-shipped, because the gasoline industry is completely broken.

      To break that down a bit...
      1) HTTPS is not an "encryption scheme" any more than Amazon is a courier service. Suggesting you can "HTTPS-encrypt" something makes about as much sense as saying that you can "Amazon-ship" a random package. Which is to say, just as Amazon relies on FedEx, UPS, and other couriers to deliver their Amazon packages, so too does HTTPS rely on cryptographic protocols (e.g. various versions of TLS and its predecessor SSL) to secure its HTTP traffic. Those protocols, rather than HTTPS itself, address user authentication, key management, and encryption.

      2) Complaining about the problems with the X.509 certificate standard is fine, just as we might complain about the problems with gasoline, but the issue of user authentication doesn't magically go away just because we don't like certificates, and let's not pretend that the alternative methods SSH supports can act as a drop-in replacement for X.509's use on a typical website, any more than an electric car can be a drop-in replacement for a freight driver today.

      3) Quick aside: SSH actually supports X.509 certificates.

      4) Continuing from #2, SSH deals with a very narrow use case (i.e. users who are purposefully logging into a server that already knows about them), which makes user authentication a simple matter that can be handled in a number of different ways, akin to the small subset of daily commuters who live close enough to work that they can choose between walking, biking, taking the bus, or driving themselves each day. In contrast, HTTPS deals with a very broad set of cases, akin to, well, everyone. Just as we can't expect public transportation to cover everyone's every need, we can't expect everyone to establish a form of trusted, out-of-band communication (e.g. login and password, use dongle, etc.) before they visit each and every random website, yet we still want to secure that traffic. X.509 is the best method we currently have for doing so.

      All of which is to say, I would not be in the least bit surprised if I've managed to misstate something here since these can be complicated topics, but starting off with a subject of "HTTPS is not the only encryption" when it isn't even a form of encryption to begin with is just asking for someone to come along with car analogies. ;)

    12. Re:HTTPS is not the only encryption by swillden · · Score: 1

      You didn't propose anything at all. You just complained about TLS and said SSH is great, not even substantiating either of those.

      The reason for my lengthy posts is to engage in a technical conversation, but you seem incapable of doing anything but whining. If you'd like to actually respond to my points, perhaps propose how an SSH-style scalable system would work, or explain why you think the proposed fixes for the CA system (including the others I didn't mention... surely you're well aware of them), I'll be happy to discuss.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  14. Re:What if the malware is baked in when you buy it by Zontar+The+Mindless · · Score: 1

    FIbre to the door here. I don't even *need* a router to connect. Of course, I have multiple devices and desire wireless connectivity, so I do need a router or similar for those things. But my provider doesn't care what I plug in on my end--any off-the-shelf device will do, as far as they're concerned. Of course, the flip side of that is that, if they see that something that affects their network adversely is coming from my connection, they reserve the right to cut it off and make me ring them up to find out why. But I suppose that's fair enough.

    (I sometimes forget how stupid and controlling American telecoms can be.)

    --
    Il n'y a pas de Planet B.
  15. Pfft. This all misses the point. by Tatarize · · Score: 3, Interesting

    If you actually care about security maybe you shouldn't let information from the internet control your computer. I mean sure they can edit your webpages via a router to insert whatever, but the inserting whatever part is could just also be malware on the internet proper.

    The point of TNO is that you might as well assume your router is altering webpages and inserting malicious content (either that or there's some already on the internet). One should view the internet as a black box of security threats and then just go from there. Yeah, routers can do that stuff. Security is what you do with that understanding. You don't get a router you can trust. You don't trust the router or the rest of the internet.

    --

    It is no longer uncommon to be uncommon.
  16. Re:What if the malware is baked in when you buy it by SuricouRaven · · Score: 1

    I'm in the UK. We have exactly one cable company in the country - there used to be more, but there was a string of mergers until only one stood. The one is Virgin Media, and they insist on the use of their own branded router, the 'Superhub.' You can set it to disable all the routing functionality and just act as a dumb modem though.

  17. Reasons why I don't like the Internet of Things. by Anonymous Coward · · Score: 0, Offtopic

    Here's a list of reasons why I don't like the Internet of Things:

    1) Internet of Things devices could watch me while I sleep.

    2) Internet of Things devices could watch me while I pee.

    3) Internet of Things devices could watch me while I make kaka.

    4) Internet of Things devices could watch me while I pleasure myself.

    5) Internet of Things devices could watch me while I wash my body in the shower.

    6) Internet of Things devices could watch me while I relax in the tub.

    7) Internet of Things devices could watch me while I brush my teeth.

    8) Internet of Things devices could watch me while I make passionate love to my wife.

    9) Internet of Things devices could watch me while I brush my hair.

    10) Internet of Things devices could watch me while I read a book.

    11) Internet of Things devices could watch me while I read Slashdot.

    12) Internet of Things devices could watch me while I bake cake.

    13) Internet of Things devices could watch me while I put in my contact lenses.

    14) Internet of Things devices could watch me while I get ready to play golf.

    15) Internet of Things devices could watch me while I do my laundry.

    16) Internet of Things devices could watch me while I think about rugby.

    17) Internet of Things devices could watch me while I tie my shoes.

    18) Internet of Things devices could watch me while I celebrate the 4th of July.

    19) Internet of Things devices could watch me while I water my flowers.

    20) Internet of Things devices could watch me while I eat ham.

    21) Internet of Things devices could watch me while I use my stapler to staple documents.

    22) Internet of Things devices could watch me while I chew bubble gum.

    23) Internet of Things devices could watch me while I check the oil in my car.

    24) Internet of Things devices could watch me while I look for my TV remote.

    25) Internet of Things devices could watch me while I blow my nose.

    26) Internet of Things devices could watch me while I rearrange my stamp collection.

    27) Internet of Things devices could watch me while I listen to the Backstreet Boys.

    28) Internet of Things devices could watch me while I do my calisthenics.

    29) Internet of Things devices could watch me while I search for a paper clip.

    30) Internet of Things devices could send information about me to advertisers.

    31) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I sleep.

    32) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I pee.

    33) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I make kaka.

    34) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I pleasure myself.

    35) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I wash my body in the shower.

    36) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I relax in the tub.

    37) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I brush my teeth.

    38) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I make passionate love to my wife.

    39) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I brush my hair.

    40) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I read a book.

    41) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I read Slashdot.

    42) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I bake cake.

    43) Internet of Things devices could let advertisers use the data unsuspectingly coll

  18. Re:What if the malware is baked in when you buy it by pnutjam · · Score: 1

    Put your own router behind the ISP's and terminate it to a VPN, game over.

    --
    Cheap storage VM.
  19. Re:What if the malware is baked in when you buy it by TWX · · Score: 1

    You can for ADSL routers. Cable service routers usually combine modem and router into one box, and DOCSIS authenticates this device with the other end of the network cryptographically - even if you wanted to replace it, you couldn't. If you check the fine print you'll usually find that the modem-router is the property of the cable company and serves as the demarcation point.

    On Cox Communications networks you can use your own Cablemodem, but it must be one from an approved list. Unfortunately that means no buying a used Cisco 2800-series router and throwing a DOCSIS module into the HWIC slot, even if theree was a DOCSIS module conforming to a new enough standard.

    All one has to then do is contact them and have them "provision" the modem, which I assume means entering its OUI into your customer record that it appears in their allowed-devices list.

    --
    Do not look into laser with remaining eye.
  20. Re:What if the malware is baked in when you buy it by pnutjam · · Score: 1

    I have another router behind mine. It terminates to a vpn. I also push some ports to it from the ISP's router. Any device I want to have on the VPN, I just change the gateway. If I don't want it behind the vpn, I change the gateway back.

    I could also just have my router do the dhcp and use some rules to decide what traffic uses the vpn.
    My point is that even without a pass-through mode, you can use your own router to protect your devices.

    --
    Cheap storage VM.
  21. FCC to ban Open Source Routers Soon... by Anonymous Coward · · Score: 1

    The FCC has an open rulemaking proceeding that would expand these requirements beyond the 5 GHz U-NII devices covered by the OET document to all Part 15 devices. See paragraphs 45 and 46 on page 18 of the Notice of Proposed Rulemaking (FCC 15-92):

        We propose to modify the SDR-related requirements in Part 2 of our rules
        based in part on the current Commission practices regarding software
        configuration control. To minimize the potential for unauthorized
        modification to the software that controls the RF parameters of the
        device, we propose that grantees must implement well-defined measures to
        ensure that certified equipment is not capable of operating with
        RF-controlling software for which it has not been approved. [ . . . ]
        We seek comment on these proposals.

    -- http://transition.fcc.gov/Daily_Releases/Daily_Business/2015...

    Anyone interested should file public comments with the FCC in ET Docket No. 15-170 by August 16: http://apps.fcc.gov/ecfs/proceeding/view?name=15-170

    While some are saying they already ban open source routers these are recent things and the community needs to stand up. There has been an increase in locked down routers and because of these newer rules all upcoming routers will be locked. You need to file objections with the FCC if you want this to stop. That is the only way we'll even begin to get rid of them and secure our routing devices. It's already near impossible to get a 100% free router where we have access to all the sources. ThinkPenguin's been working on fixing that, but can't do it if the FCC bans this. Check out librecmc.org

    1. Re:FCC to ban Open Source Routers Soon... by KGIII · · Score: 1

      We should fill that public comments section up with traditional Slashdot posts. These should even include GNAA, Goatse, and many others calling them 'fags' or whatnot. It would be priceless.

      --
      "So long and thanks for all the fish."
  22. Routers need to be secure because... by Anonymous Coward · · Score: 0

    While you should use encryption between individual devices (ie your computer and the server) it's just not possible with certain consumer devices today particularly within your network. That shouldn't be a problem if your on a switch based network and plugged in. The problem is that if the router is compromised then it can ready everything your doing that is unencrypted within the network. Things like printers are a perfect example. These devices need to be secured- particularly the router as its the first line of defence from the outside where attacks are most likely to come from. We aught to have free software printers (ie sources are available for the firmware which runs them) as well, but unfortunately I've never heard of any effort to free one. ThinkPenguin's has made sure to only sell models where there are no binary blobs required at the OS level- which is better than nothing-but not nearly enough if we want to really be secure. However it takes a lot more customers than ThinkPenguin's going to have to pull off every reverse engineering project-or other effort to get companies to completely release the code for there devices.

  23. Re:What if the malware is baked in when you buy it by ewibble · · Score: 1

    Simpler and more likely solution for the government, just watch everyone.

    If not that, Oh yes, you bought a router for cash, definitely watching anyone who does that.

  24. car cell phones by Anonymous Coward · · Score: 0

    i Cant wait till they start flipping guages on our dash over de-activated onstars and low jacks sir you need a new engine the entire Dash cluster is lit up, but im getting good gas mileage!

  25. Jeff Atwood cofounded StackOverfail by Anonymous Coward · · Score: 0

    Nuff said.

  26. Re:What if the malware is baked in when you buy it by adolf · · Score: 1

    Why must the router and modem be a single bit of kit? Don't we have Ethernet to serve as a well-developed cross-connect?

    What could possibly be gained from a suitably-new DOCSIS module in a Cisco 2800-series router (or, in my case, an impossibly-conformant VDSL module on aa Asus RT-N16) that cannot be accomplished with a provider-provided Ethernet-connected modem (whatever that is) and an Ethernet-connected router of my own choosing?

    These Cisco 2800-series routers you speak of: They do have Ethernet, don't they? Is there magic within? Or is a local Ethernet connection taboo somehow, compared to having all physical interfaces present on one device?

    It is IP, at least: Isn't it?

    (If I'm worried about MITM attacks, I'll solve my quandaries in an end-to-end sort of way using well-known and secure methods. The medium, whether including a modem or carrier pigeon, does not matter.)

    --
    Kid-proof tablet..