8

For the purpose of this question, let assume that an SSL/TLS connection has 4 parameters:

  • protocol,
  • symmetric encryption method,
  • asymmetric encryption method,
  • MAC.

During the negotiation of SSL parameters, a browser tries to achieve the best possible parameters. So, my questions are:

  1. What is the proper order of the previous list? I know that all of them important (needed). But I assume that in the code one of them is chosen as the first, then there is second, third and fourth. I believe that choosing TLSv1.2 with DES is more secure than SSLv3 with AES256. So the question is how it is implemented in the browser.
  2. Where does browser store this information and whether it can be changed by user?

I know that there can be probably couple of browser-dependent answers, but maybe there are some general rules enforced by SSL/TLS protocol.

Community
  • 1
boleslaw.smialy
  • 1,627
  • 2
  • 15
  • 25
  • They're all important. Without one of them the connection could be insecure. – RoraΖ Jul 24 '15 at 12:07
  • A related question/answer [regarding cipher suites](https://security.stackexchange.com/questions/65622/client-server-encryption-technique-explanation-tls-ecdhe-rsa-with-aes-128-gcm-s) – RoraΖ Jul 24 '15 at 12:14
  • @raz: thanks, but it does not exactly answers my questions. – boleslaw.smialy Jul 24 '15 at 12:23
  • @raz: I know that all of them important (needed). But I assume that in the code one of them is chosen as the first, then there is second, third and fourth. I believe that choosing TLSv1.2 with DES is more secure than SSLv3 with AES256. So the question is how it is implemented in the browser. – boleslaw.smialy Jul 24 '15 at 12:26
  • Is there a particular browser you're interested in? They use different mechanisms. – gowenfawr Jul 24 '15 at 12:31
  • @gowenfawr : we can focus at the two most popular browsers: Chrome and FF. – boleslaw.smialy Jul 24 '15 at 13:54

3 Answers3

6

In SSL, the key exchange, symmetric encryption and MAC algorithm are all grouped together into a single aggregate notion called a cipher suite.

In the initial handshake, the client sends:

  • the highest protocol version that it supports;
  • the list of cipher suites that it supports, in order of preference;
  • other things which are not relevant here.

Then the server selects the protocol version and the cipher suite that will be used. The theory is that a courteous server will choose the protocol version that is the highest that both client and server support, and will honour the client's preferences by selecting the first cipher suite in the client list that the server also supports. Existing servers are not all courteous.

Note that the protocol version is not wholly independent of the cipher suite: some cipher suites work only with some protocol versions (e.g. cipher suites with AES/GCM as encryption+MAC work only with TLS 1.2).

In any case, there is no independent selection of key exchange, symmetric encryption and MAC: the protocol is not orthogonal in that respect. Not all combinations make sense; and not all combinations that make sense are actually defined, i.e. have an allocated cipher suite identifier.

For more information on this process, you may start by reading this answer.

Browsers are more or less configurable with regards to the cipher suites they support and the order in which they send them. Usually you can activate or deactivate cipher suites (e.g. see this) but the order is under control of the browser's logic (which can change depending on the version). In any case, the server ultimately chooses, not the client (though of course the client can always force the use of a specific cipher suite by sending a list restricted to that single cipher suite).

It can be argued that the notion of "order of preference" has little meaning. In practice, the client sends a list of cipher suites that it is willing to use, and thus any of them is usable. If a cipher suite is "weak" then the client should not put it down enough in its list of preference so that the server, hopefully, will not select it; instead, the client should not include it at all. Weak is weak.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • Orthogonal! It would be much easier for me to write this question if I will remember this word :) Thanks for very extensive and complete answer! – boleslaw.smialy Jul 24 '15 at 13:23
4

@ThomasPornin's answer addresses your first question. Your second question, then, is "how does one configure the protocol and cipher suite in the browser?"

Firefox

Protocol is configured by modifying the about:config variables security.tls.version.min and security.tls.version.max. You can set the min and max to:

  • 0: SSL 3.0 is the minimum required / maximum supported encryption protocol.
  • 1: TLS 1.0 is the minimum required / maximum supported encryption protocol.
  • 2: TLS 1.1 is the minimum required / maximum supported encryption protocol.
  • 3: TLS 1.2 is the minimum required / maximum supported encryption protocol.

The list of cipher suites offered up by Firefox is controlled by the about:config variables security.ssl3.(cipher suite). You don't get to control the order with this interface, but I wouldn't worry about that; order on the client is a "preference" only, it is the server order that dominates the selection of cipher. The use of "ssl3" in the name doesn't mean it only impacts ssl3; it affects the cipher suites that can be offered by all SSL3 or TLS* versions.

enter image description here

You cannot simply add a key with a cipher name; the cipher has to be supported by the software, and newer versions of Firefox support improved libraries of cipher suites as older, insecure suites are retired and newer suites are added.

I have read that it is possible to compile the library necessary to add a new custom cipher suite, but I cannot find that reference now and I wouldn't recommend it as a general rule.

Chrome

Protocol is configured using the --ssl-version-min command line switch. For example, to disable SSLv3:

--ssl-version-min=tls1

The list of cipher suites can be reduced from the default using the --cipher-suite-blacklist command line switch, referencing the values from the IANA TLS Cipher Suite Registry.

--cipher-suite-blacklist=0x0005,0x0004

There's an excellent discussion here which touches on how the different browsers make their cipher suites accessible, and more particularly how they don't go out of their way to make it easy or possible.

Community
  • 1
gowenfawr
  • 72,355
  • 17
  • 162
  • 199
  • just to make it clear: isn't possible in FF to enable/disable some particular cipher suites, right? – boleslaw.smialy Jul 27 '15 at 08:43
  • And also: why you claim that "order is more important on the server than the client"? Isn't a client who sends the list of preffered cipher suites at the first place (ClientHello)? – boleslaw.smialy Jul 27 '15 at 08:45
  • @boleslaw.smialy Yes this is true, but the [server chooses which cipher suite to use](https://security.stackexchange.com/questions/72885/in-a-browser-web-server-communication-who-decides-which-encryption-protocol-to). – RoraΖ Jul 27 '15 at 12:14
  • 1
    @boleslaw.smialy, I've tried to address your followups with edits to the answer. Hope that helps! – gowenfawr Jul 27 '15 at 13:17
  • Cheers gowenfawr and @raz ! – boleslaw.smialy Jul 28 '15 at 13:22
3

Both the client (browser) and the server support a set of cipher suites.

The browser sends its list to the server, then the server picks from its (sorted) list something they both support.

The 4 parameters don't get chosen independently. All 4 belong to one cipher suite.

Which cipher suite your browser does support you can see here. Scroll down to "Cipher Suites (in order of preference)".

You can see the list for a given server here.

HorstKevin
  • 1,338
  • 2
  • 14
  • 28