I'm just thinking about the current state of affairs regarding personal cyber security. I'm thinking most particularly about the recently revealed massive hack into U.S. Government servers. Finally, I'm thinking about those other hacks which have resulted in data loss during the past two or three years and I have a question. Does this most recent breach and all of the others we are aware of render computer security discussion pointless ? Only a question, but in the end, does it matter how and how well we secure our computers containing our personal data when that data can be accessed at the other end by hackers ? U.S. Government- hacked. State Governments- hacked. Public utilities- hacked. Defense industry contractors- hacked. Banks- hacked. Department stores- hacked. Social websites- hacked. As I see it, the concept of cyber security has become one of wishful thinking. If you have personal information at any of the above- and you do- that data is vulnerable, probably compromised, and you can do nothing about it. So what are you protecting by moving to a more secure operating system or this months' top-rated AV ? With the possible exception of targeting very specific and very high value data, cyber thieves are seldom interested in that single personal computer, and why should they be when personal information for tens of thousands can be accessed with a single hack. Just wondering out loud.
Yes, it's horrible that so many incompetent fools have our confidential data. And yes, it's horrible that we're surveilled for control and profit. But we can still protect ourselves from criminals. And we can take steps to protect online privacy, and compartmentalize to limit damage.
The commonality across all of them is that, for these entities, it's really Someone Else's Problem. Fines are either nugatory or pointless (in the case of governments), and in any case, only apply to the corporate entity, not to individuals. No director or company officer is going to go to jail. Government employees have virtual immunity from prosecution of any kind, certainly if they're in senior positions. So, I don't agree they are incompetent fools at all. They have no personal skin in the game, in fact the opposite - their personal kudos, bonuses and career advancement all lie in short term profit and in implementing the hair-brained projects their leaders have foisted on them - usually vanity and functionality. Security, and particularly privacy, is simply not a bottom-line item. And then there's the extremely hard or impossible task of extracting even civil remedies for loss or negligence for these data breaches. And then, some of the current legislation seeks to indemnify corporations from hacking on the basis that they've done this data sharing stuff, as if that will reduce the hacking or damage; again, Someone Else's Problem. And then there's the control and profit motives for over-collecting, monetising and over-retention. Given that that awful scenario is our reality, the prevailing weather, I agree that there is a limited amount that can be done. But the obvious is to restrict and obfuscate what you must put out on internet services, and work to protect what realm you do (physically and logically) control - because that renders you a harder target than the mass of low-hanging fruit that is the bulk of the "market". For me, the worst aspect is that of coerced information that the government demand (and illegally take) online. Not only are they demonstrably poor at keeping it safe, they are in a position to fine you for not providing the information or for it being inaccurate. Perhaps the very worse, for me in the UK, is the government's shocking desire to monetise health-care records - I am very very happy to share mine anonymously because it would be a huge collective good - BUT only if not shared with commercial organisations for profit. But I think they will do this and say sorry afterwards. Again, none of them going to jail.
I think it is clear there has been a concerted effort over the past two decades by government and corporations to coerce and deceive the public into using deliberately below par computer security that they can easily bypass and we should no longer trust any of them.
In my opinion TLS is more of the same. lets anylize the protocol for a minute. Client connects to server. Client request secure connection and tells server what ciphers it supports. Why does it do that now in plain text ? Server picks a cipher from clients list and a hash function and tells client what it chose. Why does it do this now also in plain text ? Server now sends its certificate also in plain text. I think there is something wrong with that picture. Client now authenticates certificate with CA Client uses servers public key to encrypt a random number to send to the server. This random number will be used to create a master secret which is used to create the encryption keys for client and server. Why use a random number when we all know random strings are far more secure. Why do we need to create this shared secret to create symmetric encryption ? This means an attacker who breaks the encryption has access to the entire conversation. We dont want a MITM to be able to interfere with the communication so here is my model; 1. Client generates its own per session public/private key pair. (This pair does not have to be super encrypted that would take several seconds to generate. It is only used for the negotiation so only needs to resist attack for a few seconds. It should take less than a second to generate an adequate per session public/private key pair.) 2. Client connects to server and requests secure connection. 3. Server replies by sending it's public key only. 4. Client replies by encrypting it's public key with the servers public key and sending it to server. 5. Server responds by encrypting it's certificate with clients private key and sending it to client. 6. Client authenticates server certificate and displays fingerprint for user to verify manually if they so wish. 7. If user clicks ok client uses server's private key to request server's list of supported ciphers. 8. Server encrypts list of ciphers with clients public key and sends them. 9. If server only supports weak ciphers, client alerts user. If server supports stronger ciphers than client supports client alerts user to upgrade installed ciphers. 10. Client chooses best cipher the server supports and tells server which one to use. 11. Server now generates session keys for that cipher and sends them encrypted with the clients public key. 12. Client now generates its own session keys for that cipher and sends them to server using servers keys. 13. Server encrypts all futher communication with clients keys, client encrypts all further communications with servers keys. Attack surfaces would be vastly reduced. Attacker must be masquerading as the website from the very beginning or at the very least has stolen the web site's certificate in order to gain access to the negotiation and interfere with it. Final encryption is not symmetric so attacker would have to break the encryption twice to read both sides of the discourse.
Unfortunately, your idea is still vulnerable to MITM attacks, especially if the ability is built into the network. Insert a MITM that both responds to the client and generates its own keys to send to the server at step 2. How would you detect it or defend against it? There is no way to be sure that the key you send is the key that the server receives or vice versa. Both can be replaced on the fly by a MITM. There are things that can make it more difficult, like sending an image of the key in addition to the key itself, but this requires a person to compare them. It's feasible for the client, not for a busy server. There's no safe way to send a key on a connection that may be MITM'd from the very beginning.
Yes a MITM could be inserted at step 2 but the attacker would also have to be in possession of the servers certificate to pass the authentication test at step 6 This is why I included the fingerprint test which requires the user to view it and OK it. I know that is not infallible, users click ok to things without even reading them all the time but at least it would remind savvy users to manually confirm the certificate. If an attacker has a stolen certificate or a CA issued a fake one for attacker to use it is game over. If the server uses a self signed certificate and the user fails to notice the one received from an attacker has the wrong fingerprint it is game over. If the MITM did not have a certificate that passes CA authentication and the users scrutiny, the MITM would only gain possession of the servers public key and the clients one time public key (useless). You could also say at step 6 client compares public key of certificate with the public key the server sent at step 3. If they do not match the connection fails. I notice I wrote a mistake at step 7, that should say servers public key. (not private key). The model I suggested could probably be improved I spent about 30 minutes on it. It may be better to use the servers public key in some steps that I chose to use the client public key.
the reason I wrote that post in the first place, I looked up and read the details of the TLS protocol. Right away the red flag started waving, it screams "I was designed to give a MITM as much opportunity as possible." For one, the protocol does not allow the client to use any of its own encryption during the negotiation and barely make any decision about which encryption will be used for the rest of the session. The only thing the client gets to do is tell the server which ciphers it supports and to send a random number which is used to make the shared master secret. This is the reason in the initial stages of the negotiation the server is sending information in the clear. It does not have an encryption key provided by the client. The point is the guys who design such protocols are not idiots, they don't just forget that a MITM might intercept that information and use it to aid in breaking the encryption and if you look at the protocol details, it becomes glaringly obvious something is missing and that something is a client public key. My theory is when the protocol was designed it did include a client public key but the client side encryption of the negotiation was removed for a covert reason.
@RockLobster I believe that step 5 is also a typo. It should say clients public key, not private. I don't think that we're looking at the same scenario. I'll try again and attempt to be clearer, using the same step numbers. The first 2 steps can stay unchanged. 3, Server replies by sending it's public key only, which is captured by the MITM and replaced with a forged public key which is sent to the client. 4, Client replies by encrypting it's public key with the MITM's forged key and sending it to server, which is also intercepted by the MITM and replaced with a forged client key. 5. Server responds by encrypting it's certificate with the forged client private public key and sending it to client. It's intercepted by the MITM, which now has the servers certificate. The MITM replaces the certificate and fingerprint with their own and sends it to the client. 6. Client authenticates the fake server certificate and displays the faked fingerprint for user to verify manually if they so wish. Requires coercion of or collaboration by certificate authority, both of which are likely IMO in a system where the "authority" is purchased instead of earned. 7. If user clicks ok client uses MITM's public key to request server's list of supported ciphers. Once this point is reached, the MITM can intercept, decrypt, and re-encrypt traffic in both directions. The rest of the steps no longer matter. When traffic from both directions can be intercepted and any part of it replaced on the fly, there is no way to send a public key without the risk of it being replaced. This problem is circular. Each requires that the other exists to be secure.
To prevent MitM, clients must know servers' public keys in advance. And so there must be a secure and authenticated way for distributing those public keys. I don't know to do that with the current web. The CA system is clearly hosed.
I don't believe that there is a way to do this with the current web that can't be compromised or MITM'd. Key servers can be hacked. MITM attacks can destroy the authentication process. In order to make a key exchange secure, it needs to be done without using the conventional web. Individuals who know each other can exchange keys in other ways, but for an individual to exchange keys with a server, there's no way to do it that isn't vulnerable and potentially already compromised. IMO, this is the true purpose of the NSA data center in Utah. It's also the reason that the government isn't screaming about the switch to HTTPS. They already have that problem solved and are letting people think that they're securing their traffic when in reality, it's doing nothing.
Yes, I get that HTTPS is hosed. But let's say that I have an authenticated public GnuPG key for Wilders. When Wilders updates their site certificate, they could send it to me, signed and encrypted to my public GnuPG key. Would that be secure? If so, how could that be generalized and expanded?
The problem there is making certain that the key that you have actually came from Wilders and wasn't replaced in transit. The same would apply to your key. How can you verify that they have your key and not one generated by the MITM?
The best approach that I know is using multiple channels for authentication. The more independent the channels are, the better. It's nontrivial to MitM Tor hidden services, for example. But yes, that's a hard problem. The classic GnuPG approach is F2F key parties. But that doesn't scale, and is unworkable for pseudonyms like me
Yes you are right I typoed step 5 too and I agree with your version of events I had not considered the scenario you offered where the MITM prevents the client from receiving the real server certificate and replaces it with its own forged one. Do you think it possible to weaken the attackers ability to implement that scenario ? I have a question. Didn't we used to have the option to install a servers certificate in our browsers store so it could be compared against the certificate received from the server on future connections to it ? I was just looking in firefox I don't see that option.
The last eleven or so posts in this thread demonstrate the point of the original post. Internally protecting your data via VPN, sandboxing, AV, BB, is fine but pretty much pointless if you are going to send that data to some remote location only to have it compromised there. Once out of your protected zone- your computer-, you have no control over the integrity or security of that data or in who's hands it eventually resides. -So back to the original question- paraphrased. Does discussion involving methods and practices which do not work actually serve a useful purpose given the real world reality that your personal information is open to hackers because those charged with protecting that data continually fail the challenge ?
I don't think it's pointless. Just because hackers and government agencies seem to be able to compromise servers at will doesn't mean that every server everywhere is compromised. What it should do is make people reevaluate just what kind of data they put on the web. Myself, I won't put my finances on the web. I don't shop or pay bills online. I'll browse online catalogs but if I want something from it, I'll send a money order snail mail. I won't pay bills or make purchases with debit/credit cards. When I shop, I pay cash. I don't worry about card fraud or the theft of financial info. Hackers can't take money from bank/store accounts or cards that don't exist. Regarding social media accounts, I have no such accounts. IMO social media is the biggest waste of time anyone has ever invented. I'd rather have 2 real friends than a 1000 virtual friends. If someone can't be bothered to communicate with you outside of Facebook, how do they qualify as a friend? Facebook destroys the meaning of the word friend. This is two separate but related topics. The PCs and computer network under your control can be made reasonably secure, enough that a hacker will look for an easier target. The internet is another story. It's insecure by design. For any adversary of consequence, HTTPS is a minor inconvenience, no matter what they do to it. Encrypted DNS is pointless. Hiding what site you're looking up is pointless when your system connects there immediately afterwards. Your systems next move reveals what encrypted DNS was trying to hide. IMO, the current push to HTTPS is a "feel good" response, as is encrypting DNS. These allow people to feel like they're resisting surveillance but in reality, it doesn't accomplish anything.
http://1.bp.blogspot.com/-ok5AEj0N3QQ/VV4S4SPejGI/AAAAAAAABY4/IZNLt3C8hXs/s1600/NSA_combined.png @noone_particular I bet Turmoil is the MITM that does what you described.
@wtsinnc I get your points. And yet, with compartmentalization, compromise by others doesn't matter so much. In each compartment, I never share anything that could hose other compartments. Everything that I'm up to as Mirimir could go down in flames. My other pseudonyms could as well. Or my meatspace life. But pseudonyms going down won't affect me personally. I'll be sad, of course. And my money is also compartmentalized.
Yes, compartmentalization is the way to go. It is a very effective approach, in whatever way it is implemented. Sometimes we get carried away with security and take it to an extreme that isn't justified by the needs and situation. Ross Ulbricht could have done things ten times better and they still would have got him. It might not have even taken that much longer. He was a high value target of a federal criminal investigation. Most of us will never have to deal with that kind of adversary. The goal of a more realistic and ordinary security setup will be to keep out the punks and riff raff, not a federal investigator with resources and legal backing and authority. There are a lot more reasons for privacy technology than just those created by government.
@MisterB My efforts focus on activists and dissidents. But they face the same threats that criminals do. And in fact, they are often labelled as criminals. Regarding Ross, hindsight is 20/20, and dissing the fallen is bad form. But still, his OPSEC was horrible, and the FBI totally gamed him.
I don't meant to dis Ross as much as use him as an example. The whole story is a very good one in a lot of ways. The point I'm trying to make is that there is a reasonable level of security for a given situation and there is peril in both underestimating and overestimating it. Spending resources for unneeded defenses can create weakness instead of strength. Yes, in many places activists and dissidents are directly threatened by their governments and in many more, like here in the US, they definitely run the risk of increased surveillance. So we are dealing with a group that has higher security needs, particularly in the area of privacy technology. Any time you get involved in a political struggle that involves reallocation of resources, there are conflicts and threats. Not all threats are from government. Corporations, other organizations and individuals get involved too.
His mistake was living in America. Anywhere else he probably would have got a slap on the wrist sentence followed by a high salaried job someplace. After all, he ran an internet market and took no action to prevent illegal trading on that market. I don't see how that warrants a life sentence.
Someplaces, yes. Anywhere, though? They manipulated him into conspiracy to commit murder. Maybe that doesn't merit a life sentence. But he could have refused to go along. He could also have refused to start dealing personally at the wholesale level. That would have been extremely prudent, given that he clearly had no clue about relevant OPSEC.
