Tag Info

New answers tagged

6

SSL was designed long ago when encrypt-then-MAC wasn't that popular yet. Even TLS 1.2, published in 2008, is pretty old by now, and while encrypt-then-MAC was preferred by then, the practical risks were underestimated for a long time. Padding oracles attacks became well known after several high profile attacks in 2010. With stream ciphers, MAC-then-encrypt ...


-1

if you do encrypt first you have to have pre-shared secret keys between client and servers? once master secret is generated then Record protocol job is to encrypt/decrypt.


1

TLSv1.1 doesn't have a different treatment of the key-exchange parameters than TLSv1.2 has. It's just a little less obvious. Let's dig into TLSv1.1 specification. On page 44 you'll find that ServerKeyExchange consists of ServerXXXParams params and Signature signed_params. Now on page 44 you'll actually find a definition of Signature. This definition signs ...


1

Given your ideal setup, I don't think you need anything else than plaintext authentication. The only thing could be if the server at the end of the TLS link is not the one managing the authentication (in which case you do not necessarily want to reveal to it your password).


1

How does TLS ensure the use of the best crypto method both the server and client share? It does not. The server is responsible for selecting the cipher and there is no guarantee that it will select the best. But, if a man-in-the-middle tampers with the ClientHello to change the ciphers offered to the server, then this tampering will be detected at the ...


1

Your scheme is not a good approach -- it is not safe. Your scheme is vulnerable to rollback attacks. Ideally, the security property we'd like is that this will select the best (highest) version that both client and server support. However, that security property is not achieved. A man-in-the-middle can force both parties to end up using the worst ...


2

This is a very difficult question. But first the standard information: Don't roll your own crypto if anyhow possible. (which isn't the case here) No protocol should be considered secure until formally proven secure. (TLSv1.2 is) That being said I can still provide "ad-hoc" security argumentations why it's likely that your handshake is (in)secure.I can't ...


0

I would be worried about the absence of any key-exchange process to establish symmetric keys. The whole problem of safe communication seems to come down to safe key exchange, and this is what TLS addresses. Some people on this site might disagree with me here, but if you are rolling your own protocol anyway, I'd imagine you would have better security (and ...


0

You are missing the entire TLS protocol. The TLS protocol first establishes session keys. These can be randomly created at the client and send encrypted to the server. After that the session keys can be used to protect the data for confidentiality, integrity and authenticity. Encryption and authentication is performed in both directions. The TLS protocol is ...



Top 50 recent answers are included