Recently I heard that Flame used MD5 checksum collision to tamper with Microsoft update.
My question is where does the MD5 checksum come into play?
From this source on Microsoft website:
Windows Update uses the Secure Socket Layer (SSL) protocol to send and receive information.
Each update is individually signed using the Secure Hashing Algorithm (SHA-1).
So where is MD5 used, is it used for authenticating the update site?
In the context of FLAME, MD5 hash collision was exploited to forge an intermediate certificate in the PKI rooted at Micosoft. The clients rely on such PKI to validate an update file really comes from Microsoft.
The certificate associated to the actual fake update file may have been signed using SHA-1 or any other strong hash algorithm. The problem is that an existing genuine intermediate PKI CA entity had its certificate signed with MD5. The attackers exploited the weakness of such algorithm to forge a second PKI CA certificate that they could use to further sign anything they liked.
SSL was not directly used in the attack (the Windows Update mechanism allows packages also from non-SSL sites).
Related
I have a question regarding SSL verification within the requests library for Python, but I believe it to me more general than that.
I am currently ignoring certificate verification because the third party API I need to connect to is using a self-signed certificate.
What are the implications for turning SSL verification off in requests? And what are the implications for not verifying SSL certificates in the real-world. Can I gaurantee the data transported is secure/encrypted?
This is a security sin, as anyone could spoof this certificate and intercept your traffic. You should just add the self-signed certificate to the trusted certificate chain of the machine which is using the API.
How you do that depends on the operating system and specific setup, but a quick google will guide you to the right solution.
Can I gaurantee the data transported is secure/encrypted?
The data is encrypted (this is TLS confidentiality guarantee) but since you did not authenticate the remote part (if you disable certificate validation or bypass all errors) you could be as well sending the encrypted content to anyone, including an attacker, which of course on his side will read it in plain, as the TLS handshake succeeded if you do not validate the remote party.
TLS provides multiple features, two major ones being authentication and confidentiality. They are orthogonal (you can have one without the other) but it may not be so useful to not have all of them.
Contrary to natural thinking, authentication is more important than confidentiality because if you have no insurance about who is the remote party, what do you gain by sending it encrypted? Nothing.
I am creating a webservice that comunicates over HTTPS.
Security is very important for me, as I cannot accept modified data, so I am thinking about adding a message diggest (signature) to check integrity... but is it needed having it over HTTPS?
HTTPS already has sufficient signing to prevent accidental modifications.
A straight message digest with no secrets provides no protection against deliberate tampering. An active man-in-the-middle attacker could easily replace the digest with their own value, recalculated to match any alterations they made.
For a signature to have value against tampering it must have been created using a secret key on the sender, and the signature must be verifiable on the receiver, which means you must have a way to pre-exchange keys between parties before use.
For the case where the client is a general purpose web browser there is no channel to do that, other than transferring it over HTTPS at which point that interaction is just as vulnerable to man-in-the-middle attacks and you gain nothing. This is a bootstrap problem.
For the case where you have a custom application client you have distributed to your users through a channel more trusted than HTTPS (eg you physically handing them copies of the code), then yes, adding a server-to-client signature based on public key crypto could theoretically provide some value. But rolling your own crypto is prone to implementation errors and best avoided.
What's the attack you're trying to counter here, that HTTPS together with the commercial CA infrastructure doesn't address well enough?
If your concern is that the PKI of commercial CAs is historically prone to occasional fraudulently-issued certificates and state-level spying, then a much simpler way of defending against that would be to run your own private CA for application use, and have your client accept only certs issued by that CA (and not the certificates built into the system like Verisign et al).
Whether through running a CA, or ad hoc signature checking, running your own PKI securely and effectively is a bunch of ongoing overhead. Be sure the public commercial PKI really can't meet your needs before going that route.
I know a bit of authentication theory, but would like to know how is it really put in practice.
There are these software patches that must be distributed periodically. To ensure that only the genuine content reaches our users, we have been advised to sign our content before distribution.
The plan is to generate a Public-Private key pair. The patch would first be signed by our private key and recipients then authenticate the downloaded patch by using our public key. Our idea of signing is to generate a hash of the patch and encrypt the hash with our private key. The encrypted hash (signature) is to be bundled along with the patch before distribution.
We have been advised further that it is a good practice to get a digital certificate for our public key from a CA and post it on a certificate server in our premises. We are told that the CA would create this certificate using its private key. Our users are expected to download the public key certificate from our server and authenticate it using the public key of the CA. Thus our users would be confident that they have the right public key from us to authenticate the genuineness of the patch.
And finally the question:
How/where can the exact public key of the CA be downloaded for authentication of the public key certificate downloaded from our server?
In what formats are these certificates available? Are these plain text files or XMLs or ??
To answer your questions in order:
Using a browser and SSL. In that case you rely on the certificate store already in the browser. It may be a good idea to also publish the fingerprint of your own certificate. Note that you also distribute a certificate - or certificate chain - within your software. If the software download is trusted, then you may not even need an external Certificate Authority. But in that case you keep your private key of the CA very secure.
X5.09 certificates are created using ASN.1 DER encoding. DER is a binary encoding (and the textual ASN.1 definitions specifies the contents). Certificates are also often distributed in PEM format. This is a base 64 encoding of the binary certificate, with an additional header and footer.
Every month there are articles on the web about some app or platform using outdated crypto configurations in its SSL implementation. This has gotten me worried... what about my own implementations?
What exactly should I do to configure OpenSSL in the most secure fashion when I use it in an app for serving and/or consuming HTTPS? (e.g. in combination with cURL)
Aside from configuration, what other steps must be taken to ensure that OpenSSL is used securely? Are there any special steps I should take, e.g. in relation to the public key infrastructure?
Is there some "known good" configuration available on the web?
Ensure that your certificate provider signs your certificate with a SHA1 or better (SHA2 preferred) hash.
HTTPS (SSL/TLS) is only effective if you verify the certificate. This is most commonly performed by the client. If the client does not verify the identity of the server by verifying the certificate, you are subject to man in the middle attacks.
You can configure the server so that it does not allow the older (SSL) protocol, and instead requires the latest TLS protocol, which is cryptographically stronger (e.g. SHA1 and MD5 in the pseudo-random function instead of just MD5 in TLS 1.0, and TLS 1.2 uses SHA2).
When creating your certificate key pair, choose a longer key (e.g. 2048 bit is preferred over 1024 bit).
There are some good recommendations on the Mozilla wiki:
Security/Server Side TLS
I am working on a project that requires an ECDH key exchange. I am trying to understand how to protect against MITM attacks. I can sign the public key and send a signature along with the public key transfer to ensure that the key has not been tampered with but that doesn't stop a MITM attack from just doing the same thing. I understand that the key exchange must be verified somehow by a third party but I'm having a hard time understanding how it is that a third party can be the solution assuming that someone can do an MITM attack. Why couldn't they just do an MITM on the third party verification too? Is there really a fail proof way of completely eliminating all possible MITM attacks without some kind of pre-known by both parties?
You need a¹ trusted third party to sign both keys.
Without any knowledge or assertions about the identity of the intended partner, there's simply no way to distinguish him² from anyone else.
¹ one or multiple
² Bob
In a PKI system, "certifying authorities" are an important part of the infrastructure. Certifying authorities sign the public key and the identifying information, so that you know the corresponding private really belongs to the purported identity. This is true for EC keys just as it is for RSA.
By the way, I've looked for CAs that issue EC certificates, and apparently they aren't in practical use.
Most people obtain certificates for their certifying authorities as part of their operating system or security application. They trust these certificates implicitly. There are several dangers here, though.
First, most users don't have an effective way to verify the integrity of these certificates. This is a pretty hard problem, because, at the root of it, you have to have a 100% trustworthy channel for the verification—channel between the authority and the user with which an attacker cannot tamper. When a user downloads a new browser with an collection of root certificates, he can't know that the software wasn't tampered with in transit, or even built with a bogus CA certificate in the collection.
Even if the certificate collection is received intact as the provider intended, there have been questions raised about the integrity of many certifying authorities included by default in popular software. For example, some have pointed out that telecommunications companies in states that have been linked to terror sponsorship have their certificates included in popular browsers. Any trusted authority can issue a certificate for any domain name, and a browser will accept it without question.
In short, no, there is no way to establish a secure channel without first sharing some information on a secure channel. The benefit of PKI and asymmetric cryptography is that one exchange on a secure channel (the receipt of a trusted authority's certificate) permits the establishment of secure channels with many parties. But you have to bootstrap the system somehow.
It sounds like you are heading down a path of rolling your own crypto protocol. Don't do that. It's a bad idea. It leads to insecure systems.
Instead, use SSL or TLS. That is designed to take care of the subtle issues in designing this kind of crypto protocol -- and it has been well-vetted. You'll need a way to verify the other endpoint's certificate. You could use a certification authority, or in some cases it might be feasible to hardcode the public key of the entity you expect to talk to.
You may get better answers if you ask on the Crypto stack exchange.