Comment Re:Who you gonna call? (Score 1) 304
Node.js is very efficient at waiting and reacting to input. One node.js instance can get up to 99% on one CPU core, something that is really hard with a Java or
Node.js is very efficient at waiting and reacting to input. One node.js instance can get up to 99% on one CPU core, something that is really hard with a Java or
And where is the problem with that? People have no idea what security is and how all pieces of it are implemented, however they are told by banks (for example) that they must have the 'https' connection (or the secure icon) and if it's not there, then they shouldn't use it.
User studies have shown that users don't pay attention to HTTPS warning messages or to the secure icon (e.g., https://www.usenix.org/legacy/event/sec09/tech/full_papers/sunshine.pdf).
Worse, how is the user supposed to know whether to check for the icon?! If you're going to bank.com it's reasonable to assume that HTTPS should be used. What about other websites? You know, the kind that the govt would actually be interested in intercepting traffic to. There would be no way to know if HTTPS _should_ be present if the attacker performs a mitm to replace the CA-signed cert with a self-signed one. With the current system the user at least receives the self-signed warning page.
- if this is your first connection to the bank, then there is nothing you can do, correct! You can't know what the certificate is for the bank until you get one. So you should be presented with a PLAIN TEXT connection to the bank if this is your first connection and if you are willing to go through a PLAIN TEXT connection to your bank, then that's up to you and if that's the MITM attack then too bad, you didn't care to check what the connection to your bank is and that it doesn't use a CA signed certificate (as if that matters if you don't care to check what the hell you are doing connecting to your bank without understanding you need to look for a 'secure' connection icon, which is what all banks tell you to do).
This is a horribly brittle approach.
What if the website switches CA-signed certs for a legitimate reason? What if they follow your advice and switch from a CA-signed cert to a trusted self-signed cert? Certs do, and should, expire.
How do you know the first cert you receive from the website is the correct one? If I wanted to defeat your approach, all I would have to do is ALWAYS replace the CA cert with a self-signed cert. Your approach isn't implemented yet, so if I start doing that before it is, I will succeed in performing a mitm against every connection.
A self-signed certificate without MITM attack prevents gov't from looking at your past. CA that generates your keys is the biggest breach of security there is and browsers acting as if self-signed certificates are a virus coupled with CAs is a huge barrier to entry for a large number of people that prevents them from implementing self signed certificates.
You would have to be a complete idiot to let a CA generate your keys for you. The normal (and sane) process is to have the CA sign your public key. In that case what I previously posted is true: a CA-signed cert is equivalent to a self-signed cert in that, to decrypt your traffic, the govt must do a mitm or take your cert.
I didn't address that scenario in my previous comment, it doesn't mean that it is how I would address it (not give a warning when a CA authorised certificate is replaced with a self signed certificate)!
How can you possibly detect when a CA authorized certificate is replaced with a self-signed certificate? You can't ask bank.com's webserver because you don't have a secure way of communicating with it before making that determination.
There are two scenarios here: either the government performs mitm attacks or they don't.
If they do perform mitm attacks, using an untrusted self-signed certificate is equivalent to using a CA-signed certificate in terms of what the govt can see. The govt can perform a mitm on the self-signed connectino by using their own self-signed cert, and the govt can perform a mitm on the CA-signed connection by forcing the CA to give up the CA cert and signing a new cert with the CA cert.
If they don't perform mitm attacks, the govt needs the website's cert to view the traffic. This means they either need foo.com's self-signed cert or bar.com's CA-signed cert. Either way, the CA's cert alone isn't good enough.
If you don't agree with those two scenarios, please explain which details are technically correct. (I'm fairly certain that none are.)
If you do agree, then it follows that you agree that using an untrusted self-signed cert is no better than using a CA-signed cert. The secure thing to do would be to use a trusted self-signed cert; that is, a self-signed cert whose fingerprint has been verified through a secure channel.
Saying that self signed certificates are worse than plain text is either propaganda for some ulterior motive or it is an irrational position, because the end user does NOT even have to be AWARE that a self signed certificate is used! In fact if the browser doesn't even tell the user that there is a self signed certificate, then to the user it looks like a plain text connection and maybe that's how browsers really should treat self signed certificates that are not manually authorised by the user.
That browser user interface change would create a huge security hole. Consider the following scenario:
1. Alice, the user, accesses https://bank.com/ which uses a CA-signed certificate.
2. Mallory, an adversary, performs a mitm attack on Alice's connection. She replaces the CA-signed certificate with a self-signed certificate, allowing her to view all of Alice's traffic to bank.com.
With the current browser UIs, the browser would show Alice the self-signed certificate warning. Alice should see it, known she's under attack, and decide not to proceed.
With your proposed UI, the browser would show NO WARNING. Unless Alice knows that bank.com should display the HTTPS icon and notices that it isn't, she will proceed and Mallory will be able to view all of Alice's traffic.
It is COMPLETELY UNREASONABLE to expect Alice to notice that the HTTPS icon is missing. Many user studies have shown that users continue after seeing self-signed certificate warnings, which are impossible to miss and explicitly state the dangers of continuing.
If somebody, especially government is specifically targeting you for MITM attack, no CA will stop them, worse, AFAIC CAs are are highly suspect, CAs are a perfect target for government 3LAs to create an easy way to penetrate security.
Correct, and a self-signed certificate won't stop them either. Here's a simple algorithm to break self-signed HTTPS:
1. If HTTPS using a CA-signed certificate is detected, record the traffic.
2. Else if HTTPS using a self-signed certificate is detected, perform a mitm attack and record the decrypted traffic.
It's only secure to use trusted self-signed certificates, which is what I've been arguing for this entire time. If you use a self-signed certificate and click through the brower's warning, it's just as bad as using plain text.
In fact there cannot be 'secure' icon on a browser if a CA is used! The only way to have highest order of security that we can achieve right now is to install self signed certificates where we know the fingerprint and to prevent CAs from authorising anything at all on our computers.
This is why I don't think you read my post. I was careful to differentiate using "self signed certificates where we know the fingerprint" (trusted self-signed certificates) from self-signed certificates where the fingerprint is unknown. Using trusted self-signed certificates is a great idea. Using (untrusted) self-signed certificates is worse than plain text: it gives the illusion of adding security without actually adding any.
- I trust them much more than I trust governments and certificate authorities. I trust that using an encrypted connection with self signed certificate is NOT WORSE than using plain text and I don't trust that the browser behaviour regarding self signed certificates is without suspect, without a bias.
It is worse. Using an encrypted connection with a self signed certificate is worse than plain text in terms of security. With HTTP a man-in-the-middle can see everything you send. With HTTPS using a self-signed certificate a mitm can substitute their certificate for yours and see everything you send. You'll have no idea this happened because you'll see the self-signed warning either way. The difference is that with HTTP the user knows the connection is insecure and choose what data to transmit accordingly; with HTTPs using a self-signed certificate the user believes the connection is secure when it isn't.
Note that when I say "self-signed certificate" I'm referring to a self-signed certificate that your browser has not been configured to trust. If you've verified the authenticity of a self-signed certificate and configured your browser to trust it, I'm referring to it as a "trusted self-signed certificate." Self-signed certificates are insecure and worse than plain text. A trusted self-signed certificate is more secure than a traditional certificate that's been signed by a CA. Browsers support trusted self-signed certificates and don't show the warning you're complaining about when one is used. (I'm ignoring the difference between a true self-signed certificate and a certificate signed by a CA you own; it makes no difference for the purpose of this discussion, so I'm referring to both as self-signed.)
IF your argument had any merit, THEN browsers could at least use the self signed certificate and NOT show the 'secure' icon, show whatever you like, don't break browsing experience for users. Don't say that the connection is perfectly secure, but don't make it look like the user is about to access a virus infected site or something to that effect, that's where my mistrust of benevolent browser behaviour comes from.
In the vast majority of real world situations, the user is about to access something similar to a virus infected site when they see the warning. It's intended to warn the user that a mitm attack is likely taking place. If they're intentionally accessing a website using a self-signed certificate, they should verify the certificate's authenticity through a secure channel and configure their browser to trust it so that it becomes a trusted self-signed certificate.
It's never a good idea to use self-signed certificates. It is a good idea to use trusted self-signed certificates; browsers don't show the warning message when trusted self-signed certificates are used, which destroys your conspiracy theory.
Using an untrusted self-signed certificate is worse than using a certificate signed by a CA. It allows anyone to perform a mitm attack, whereas with a CA-signed certificate only powerful actors (e.g., governments) have that capability.
At this point the behaviour of browsers to treat self-signed certificates as worse than plain text should be suspect to everybody, there is no rational explanation to that sort of attitude except: we don't want you to use certificates that authorities can't revoke and replace.
I agree that everyone would be better off if everyone encrypted everything. I also agree that CAs shouldn't be trusted.
But seriously? You can't see any reason to distrust self-signed certificates? They aren't trusted because the browser has no way to verify their authenticity, which makes them dangerous. Trusting them would make man-in-the-middle attacks against SSL too easy; many studies have shown that users ignore the warnings. This _IS WORSE_ than plaintext because the user believes they have a secure connection when they don't. With plaintext the user at least doesn't expect the connection to be secure.
There's absolutely nothing stopping you from using self-signed certificates in a secure way. Configure your browser to trust specific self-signed certificates that you can verify are authentic, and you're good. It's incredibly insecure to trust _ANY_ self-signed certificate; your assertion that "the authorities" are trying to
prevent you from using them is nothing but paranoia. There are plenty of things to be paranoid about these days. This isn't one of them.
Unfortunately, you can boil the entirety of information theory to 'security through obscurity'. Airplay uses public key encryption and is in that sense 'secure'. Everything that needs to read the encrypted content (in this case the airplay device) needs to have the key to decrypt it. Thus you can argue that the whole system is 'security through obscurity' because it is relying on the 'obscurity' of the private key that the end-user can't get access to (unless the pry it open with a butterknife and dump the ROM).
Yes, you can boil it down to that, but in doing so you ignore the meaning of "security through obscurity" and replace it with a definition so broad that it loses any meaning. Name a system you consider secure that does not rely on "security through obscurity" by your definition.
See http://en.wikipedia.org/wiki/Security_through_obscurity and http://en.wikipedia.org/wiki/Security_by_design
These programs have no idea as to when to buy, sell or hold. All they do is retrieve data and analyze it into reports. It's up to the trader to know what to do with it.
That's exactly what they DON'T do. These programs buy and sell on their own, without any help from a human trader. It would hardly be high frequency trading if every trade had to be vetted by a human first.
Apple's competitors could conceivably use their Analytics groups for industrial espionage
In that case, Apple is still acting to protect itself from its competitors. Its purpose is not to protect its customers from spyware as you suggest.
Yes, and anyone can be a spy. But we still give people security clearances.
Being a spy is illegal. Apple isn't saying it's "illegal" to install spyware; they're saying it's "illegal" to be a competitor and install spyware.
Furthermore, Apple can easily prevent any risk of industrial espionage by using a firewall when necessary. The risk of espionage is a bullshit excuse Apple hides behind. Apple must understand security this basic if they're selling operating systems (or one would hope).
"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_
