1

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 ?

1

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.

  • Great. Thanks! Although Tom answered part, you better understood my ill-formatted question! :) Agree, that randomness is another factor apart from the size of the key. And yes, I meant ECDSA 256 bits, not DSA. My mistake. – user3461411 Mar 25 '14 at 23:38
2

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).

  • Thanks. That answers my first question. And in your answer, 2 - No. I didn't mean an HTTP user auth. I also didn't mean 'key size' of bulk cipher. What I specifically want to know is - authentication involves say, client encrypting a random key with server's public key and server decrypting it and sending the value back to client. Which means the authentication process is always dependent on the server certificate key size, and is only as strong as this number (most often 2048 bits for RSA certs and 256 bits for DSA/ECDSA). Is my understanding correct ? PS: Updated my question. – user3461411 Mar 25 '14 at 21:56
  • Well, when you explain what you mean by "authentication", things are clearer: what you call "authentication" is not what is normally known as "authentication". What you describe is called key exchange. – Tom Leek Mar 25 '14 at 22:00
  • my bad. Yes. Still a bit confused - in your answer you talked about the 'validation' process - ".. which indirectly authenticates the server for the whole subsequent data exchanges. .." Isn't that 'validation' process same as what I described in authentication ? Also do you confirm that this 'validation' is only as strong as server cert key size ? – user3461411 Mar 25 '14 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.