Hot answers tagged ssl
19
The SSL and TLS protocols (on which HTTPS is based) are designed in a way that no attacker (neither a passive nor an active one) can read anything of the encrypted part (if the cryptographic assumptions hold - and if you don't use the NONE cipher, which does no encryption).
Of course, the attacker can read the negotiation part. But this part will not ...
18
Academically speaking, RC4 is terrible; it has easy distinguishers ("easy" means "can really be demonstrated in lab conditions"). It is also hard to use properly. However, SSL/TLS uses RC4 correctly, and in practice the shortcomings of RC4 have no real importance.
The power-that-be at Google decided to switch to RC4 by default because of the recent "BEAST" ...
12
Say you encrypt a message with a key $k$.
With symmetric encryption (ie. symmetric ciphers), $k$ must be secret. The sender and recipient must agree (somehow) on $k$. No-one else can be allowed to find out $k$. Anyone else who finds out $k$, can decrypt all the messages encrypted with $k$. For that reason, symmetric ciphers are often called "secret key" ...
11
That's not quite correct. In SSL, two things happen:
First, a session key is negotiated using something like the Diffie-Hellman method. That generates a shared session key but never transmits the key between parties.
Second, that session key is used in a normal symmetric encryption for the duration of the connection.
SSL does use public/private in one ...
11
By George, you're on to something.
To answer the question you asked, I don't know of anyone actually attempting to recover a password this way, or it even being discussed. However, it does appear to be feasible, given enough encrypted streams.
How many are enough? Well, I've started running a few simulations; preliminary results indicate that with ...
9
The recently demonstrated attack against SSL (BEAST) was an IV misuse attack and not really the same thing as what happened to XML Encryption. Non the less, here is what happened with SSL.
Basically they found two things:
A way to get the browser to encrypt data under the session key used by an existing SSL connection and
A mistake in the way SSL was ...
9
Wikipedia has a decent writeup on the known attacks on RC4. Most of them are from biases of the output. To give you an idea of the severity of the attacks see the following quotes from the Wikipedia page:
The best such attack is due to Itsik Mantin and Adi Shamir who showed that the second output byte of the cipher was biased toward zero with probability ...
9
The server doesn't sign the data itself. It only signs part of the handshake if you're using a signing based suite. That means you can prove to a third party that a handshake with a certain server happened, and what data was exchanged in that handshake.
If you're using a RSA encryption suite, it doesn't even sign the handshake, but authenticates indirectly ...
9
The reason why you see that is because Camellia is the highest-preference cipher in NSS (Chrome and Firefox). Servers that support Camellia and use the client-preferred cipher suite will use Camellia.
NSS's rationale for this ordering is:
National ciphers such as Camellia are listed before international
ciphers such as AES and RC4 to allow servers ...
8
To complete what @CodesInChaos explains:
If the server has a RSA key in a certificate which is suitable for encryption, then anybody can forge a completely fake conversation without the server being involved at all. In the SSL/TLS protocol, when using a "RSA" cipher suite, the client generates the random "pre-master secret" which it then encrypts with the ...
7
For TLS the IV for the first packet is generated from the shared secrets; quoting the RFC 2246:
To generate the key material, compute
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
until enough ...
6
There are several effects coming into play. But the most important property is that with increasing keylengths, the attacker's work becomes exponentially expensive, whereas the defenders work only becomes a bit more expensive.
Looking at the different kinds of cryptography in use:
Symmetric cryptography
Originally we used DES and 3DES. DES had a ...
5
Well, what SSL uses to negotiate the symmetric keys depends on the ciphersuite that both sides agree upon. By far, the most common method is that the client picks a random value (the premaster secret), and encrypts it with the server's RSA public key. However, it is not that unusual for the ciphersuite to specify that the client and the server agree upon a ...
5
Yes, it is. Because of the way public key crypto works, they wouldn't be able to decrypt it.
First, realize that something encrypted with a public key can only be decrypted with the corresponding private key (or, depending on the algorithm, vice-versa).
So lets say everyone (including the sniffer) has the server's public key. You encrypt something with it, ...
5
I wouldn't assume that the NSA has cracked AES ciphers. I would assume that most crypto systems that use AES have implementation flaws that the NSA exploits when they feel it is worth it.
In any case, when the only possible way a state can know something is by breaking a cipher, it's difficult for them to use that information; doing so would reveal that ...
5
An interesting thing about some modern standardized ciphers, like AES, is that the government is "eating its own dogfood" by using them internally. (AES 192 and 256 are approved for top-secret data.) Back in the day (up through the 90s), U.S. government internal encryption standards was not closely aligned with public sector cryptography, and we largely had ...
5
I know of two standard protocols that support AES encryption without public key cryptography getting involved:
With TLS, we have RFC4279, and in particular, the ciphersuite TLS_PSK_WITH_AES_128_CBC_SHA. Now, the two sides don't literally have preconfigured AES keys; instead, they have preshared premaster secrets; the AES (and HMAC-SHA1) keys are derived ...
5
TLS not only provides privacy, but also authentication:
You can be sure you know who you speak to (at least the client knows if the server was using a certificate). (You provide this by the "HTTPS key exchange" you are doing at the start.)
You can be sure that you speak to the same entity at the other side throughout the whole live of your connection (even ...
5
Assuming that the keys used for the SSL and SSTP layers are independent (which they should be, since both layers have their own separate key setup processes), compromising the outer layer (SSTP) cannot make the inner layer (SSL) any less secure than it would be if used alone.
To see why this is, imagine that there was an attack that did allow breaking SSL + ...
4
RC4 is a stream cipher and can be easy to misuse. E.g. Microsoft had problems with it to protect password and office documents. However its use is, afaik, correct inside the SSL/TLS specification.
Like often in cryptography things are easier to misuse than to use ;-)
4
No; the problem with XML is that it doesn't include a Message Authentication Code (MAC), or anything else to validate the ciphertext; the only validation that XML does is checking if the CBC padding is sane. The attack uses that as an Oracle to decrypt data; the attacker generates an encrypted region with the last two blocks being carefully chosen; if the ...
4
Certificates use asymmetric cryptography: here, the client generates a public key, gets it "authenticated" (signed) by the server, and later on proves his knowledge of the private key to the server (as part of certificate-based client authentication in SSL).
Certificates are useful when the certification authority (the party which "issues" the certificate, ...
4
To use a symmetric algorithm for encryption or key-exchange in a way that is secure (i.e. no observer can read the data), both parties (i.e. Alice and Bob) need to have some pre-existing common secret which is not known to any other party (i.e. Eve).
There are such pre-shared key algorithms, and they can be used with SSL. But they are not useful for the ...
4
You can use TLS 1.0 as guidance: it is the direct successor of SSL 3.0, so many things are quite similar, and in some respects TLS 1.0 is a bit clearer. In section 6.3 you will find the key generation process, with the exact sentence:
To generate the key material, compute [...]
until enough output has been generated. Then the key_block is
...
4
In TLS (that's the standard name for SSL; TLS 1.2 is like "SSL version 3.3"), client and server ends up with a shared secret (the "master secret", a 48-byte sequence; when using RSA key exchange, the master secret is derived from the "premaster secret" which is the 48-byte string that the client encrypts with the server public key). That shared secret is ...
4
The "Common Name" is part of a X.500 name; here, the one called "SubjectDN", which designates the owner of the public key which is contained in the certificate. That name is part of the certificate, in the part which is covered by the signature; as such, it is exactly as trustworthy as any other element in the certificate.
4
Only two people can communicate with each other with the chat program.
No group conversations.
This is fairly limited, but let's admit.
The people will be communicating over the internet.
So, an insecure channel. OK.
The chat program will just handle basic characters, numbers and
symbols that are on a standard US keyboard. This is to keep ...
4
If all the components share the same certificate, then they share the same private key. This raises the two following points:
When a secret is shared by more than two people, can it still be considered really secret ? Secrecy dilutes fairly fast. If all components share the same secret value, then breakage of any single component reveals the private keys ...
3
SSL does more than just encrypt the data. It also protects it from undetected modification. To do this, when it encrypts data, it also generates a cryptographical checksum (which is termed a message authentication code or 'mac') of the plaintext record, and includes that in with the encrypted record. Now, to make sure that someone in the middle can't ...
Only top voted, non community-wiki answers of a minimum length are eligible
