|
|||
Duqu - Stuxnet sibling
Quote:
Quote:
|
|
|||
https needs to be redesigned so it's not vulnerable to "man in the middle attacks". Couldn't certificates be replaced with public key cryptography?
|
|
|||
So what could be the solution to the problem as these attacks are becoming more wide spread? I heard that there are companies that specialize in setting up MIM attacks.The way the MIM attack server works, is, it intercepts your request for https, it submits your request for you, gets your certificate, and then passes on the information to you, and your browser can't tell the difference.
|
|
||||
I'll try to explain why I believe the problem is the use of certification chains (chains of trust), and why that trust breaks down, with the cryptography being moot.
--- 1. Pre-Shared Keys Alice and Bob exchange messages, using keys they have shared previously, in a secure manner. They must trust each other. Each relies on the other to keep both the unencrypted messages (the plaintext) and the keys secure. That is, Alice must trust Bob not to publish, expose, nor permit the theft of any part of the plaintext or the keys. And Bob must trust Alice to do the same. 2. Public keys Alice and Bob each create key pairs. A key pair contains two components: a public key and a private key. Bob and Alice can exchange their public keys without having to do so securely. They must still trust one another not to disclose, expose, or publish any portion of their private half of their key pairs, or of any plaintext. The trust is still two party as with pre-shared keys. 3. Certificates A certificate is a key management tool, which adds lifespans, revocations, and the ability to add third parties to the trust mechanism. 3a. Self-signed certificates Very similar to using public/private key pairs, as in 2. above. Alice and Bob must still trust each other. Bob can revoke a previous certificate he used with Alice, effectively terminating its lifespan early. He may do so if the private key were exposed, for example. 3b. Certificate Authorities Alice and Bob can use a third party to manage their certificates, and authenticate that the CA issued them to Alice and to Bob. Alice and Bob must still trust each to keep their private keys and plaintext secure. And, Alice and Bob must now trust the CA they have engaged to do the same. 3c. CAs and chains of trust CAs can be trusted by other CAs. Alice may engage Charlie and Bob may engage Eve to act as their certification authorities. Do Charlie and Eve trust each other? Maybe. But their connection may be indirect. Between Charlie and Eve there may be additional CAs Frank and George. Alice and Bob must now trust each other, and Charlie, Eve, Frank, George. 3d. Browsers and host certificates The HTTPS protocol requires that the web server authenticate via certificate. The clients - browsers - can also authenticate with certificates but this is optional. (Most public-facing web applications do not use client certificates, requiring passwords or other forms of authentication when needed.) Certificates can be self-signed or can use CAs. Browser developers provide a pre-set collection of certificates. These are certificates from CAs the browser developers happen to trust. Continuing our example, if the browser developer added Charlie to the list of valid certificates, any certificate issued by Charlie or issued by a CA Charlie trusts, or by a CA trusted by a CA Charlie trusts, or by a CA trusted by a CA trusted by a CA Charlie trusts....(ad infinitum) will be trusted by the browser. ---- And it's these long chains of trust which I believe are the problem. CAs have been compromised. Not only private keys, but certificate production capabilities have been stolen, which permit bad actors to create what appear to be trusted certificates. Certificate revocations and CA revocations are always after-the-fact; because they only occur once these breaches (of trust!) come to light. |
|
||||
Now, let's look at one form of MITM usage, "SSL Interception," commonly used with web proxies. To do this, we turn our attention again to Alice and Bob. Here's one common way this is done.
Alice wants to use Bob's web server. Alice is employed by Eve, who permits access to the Internet only through Eve's HTTP/HTTPS proxy server. Eve has provided Alice with a certificate for Eve's local CA, which is installed in Alice's browser. All workstations at Eve's company use the proxy and have this local certificate installed. Eve's proxy server intercepts all URLs on behalf of Alice's workstation. For HTTPS connections, the proxy server generates certificates on-the-fly , which Alice's browser will trust ... because the local CA is trusted by Alice's browser. Bob's host certificate is provided to Eve's proxy, but never reaches Alice. Alice receives Eve's certificate, which she is forced to trust. If Eve is using OpenBSD, Eve's proxy server can be relayd(8). SSL Interception was added at the end of 2012. The developer, reyk@, discusses it in this blog post. |
|
|||
Quote:
|
|
||||
Here's an interesting paper, Security Collapse in the HTTPS Market: Assessing legal and technical solutions to secure HTTPS, published by the ACM.
Quote:
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Stuxnet Espionage Worm | shep | News | 5 | 13th February 2011 04:31 PM |