SSL/TLS : Authentication mechanism

Question

I have these doubts regarding authentication in SSL/TLS :

• Will there be an authentication involved for all SSL connections ? For eg. when I browse the internet, using the most up-to-date browser, can I assume that there is always authentication involved ? From other questions I learnt that they are mostly to avoid a MITM. But is it optional/mandatory ? RFC says,

This authentication can be made optional, but is generally required for at least one of the peers.

• If yes, does it always depend on the server certificate key size ? Say for eg: RSA public key size 2048, DSA key size 256.
• When referring to the cipher suite used for SSL - is it okay to say the authentication happened with the <Auth> algorithm with <server_cert_key_size> ? ( Considering I'm using cipher suite : TLS_<Keyexchange>_<Auth>_<EncCipher>_<MAC> ). I know the authentication mechanism differs by the type of key exchange (DHE vs. RSA), but is the usage of <server_cert_key_size> consistent ?

Sorry for asking 3 questions in one. But they are very much related.

EDIT: To rephrase, and to be precise - is SSL/TLS authentication only as strong as the server certificate key size ?

Answer 1

Your Web browser will always try to authenticate the server's certificate; it will complain loudly when it cannot. The point about optional authentication is for the "DH_anon" cipher suites in which there is no authentication at all. Such cipher suites are, by definition, insecure against active attackers, and thus should not be used. Web browsers don't support them by default, or even at all.

Some servers may also require some certificate from the client, but this is pretty rare because client certificates are a rarity, and most people don't have any. This mostly occurs with some bank sites, and if that's your case then you should already know it.

Key size does not impact whether authentication occurs or not. Of course, if the server uses a pathetically small key, this may endanger the safety of communications -- but your up-to-date browser should warn you in that case.

The key size as indicated in the cipher suite name (as the "128" in "TLS_RSA_WITH_RC4_128_SHA") does not relate to the RSA / DSA / whatever key used for the asymmetric encryption, but to the symmetric encryption algorithm used afterwards to actually encrypt the bulk of the data.

---

More generally, you seem a bit confused about what "authentication" means. In usual SSL connections, between a Web browser (the client) and a Web server, along the HTTPS protocol, there are two "authentications" which take place:

1. During the initial establishment of the connection (the "handshake"), the server shows his asymmetric public key to the client as part of its certificate, and the client validates that certificate. The validation process is the method by which the client makes sure that the public key it sees is indeed owned by the intended server. Once the client has obtained some guarantee that the public key is correct, it accepts to use it for the cryptographic elements of the handshake, which indirectly authenticates the server for the whole subsequent data exchanges.

2. Once the handshake has been done and the SSL/TLS tunnel established, the server may require some sort of authentication from the client (password, cookie...). This happens at the HTTP level, not at the SSL level; this is completely unrelated to SSL, except that most client-to-server authentication mechanisms can be deemed "safe" only when they occur within a secured tunnel, e.g. some established SSL connection.

The relationship between the cipher suite and the authentications is the following:

• The cipher suite may mandate a specific key type (e.g. RSA or DSA), and things will work only if the public key, as found in the server's certificate, is of that type.

• The client-to-server authentication is secure only insofar as the SSL/TLS tunnel ensures confidentiality and integrity; there are weak cipher suites which do not do that well. Fortunately, these cipher suites were defined to comply with old US export regulations and are no longer activated by default or even supported by modern Web browsers (except maybe in some countries, which may insist on their citizens using weak cipher suites).

Answer 2

can't comment, but I agree with @Tom's answer, with a few points to add:

SSL/TLS server authentication depends on the "strength" of the server key -- both its size, which you can see, and that it was sufficiently random, unlike for example the Debian openssl packages a few years ago that used a crippled RNG or the thousands of apparently unattended devices that the EFF web survey (I think it was) found to have "randomly" duplicated RSA primes, allowing trivial GCD factoring -- and also the "strength" of the cert -- was it issued by a CA that adequately checked the identity of the Subject, and did the Subject protect its privatekey.

For RSA keyexchange, client encrypts premaster-secret and sends to server which decrypts but does NOT send back; instead both parties use it in key derivation to produce among other things Finished MACs which are checked. For DH and ECDH keyexchanges, there is no encryption (until the bulk data), but for the ephemeral cases, server signs ServerKeyExchange which proves possession of the privatekey (modulo the recent Apple "goto fail" bug).

The size of an integer DSA key (or static DH but nobody uses that) needs to be nearly the same as RSA -- currently for good security 2048 or thereabouts, and everybody uses the round power-of-two. FIPS 186 never allowed less than 512 for DSA, and today not less than 1024 and that only in limited cases. *EC*DSA or *EC*DH is much smaller, currently 224-256.

Using export ciphersuites does NOT weaken authentication, or even data integrity i.e. HMAC, only confidentiality -- which is bad enough. For that matter there are even defined "null encryption" suites which do authentication and HMAC but no encryption at all -- almost always a bad idea, and rarely implemented or used, but still arguably better than plaintext.