[gnutls-devel] overall sec_param (weakest link) for a gnutls session?

[Matthias-Christian Ott]

On 12/04/13 00:11, Matthias-Christian Ott wrote:
> On 2013-12-03 23:20, Daniel Kahn Gillmor wrote:
>> What do folks think about this idea?
> 
> +1

I thought about this for some time and want to revise my position.

There are three categories of cipher suites: insecure, possibly insecure
and secure. At the moment a software developer or administrator
categorises the available cipher suites as either insecure (drop
connection) or secure (accept connection). Daniel proposed to add at
least another category: possibly insecure/low security margin. If the
cipher suite is in this category the application accepts the connection,
but displays only data with a low confidentiality level or something
similar to limit the damage in case of a MITM attack.

The scenario I had in mind was the following: The application has a
client-server architecture. The server has all the data and is operated
by security-concious people (e.g. a web server of a bank). However,
these people have no control over the client (e.g. a web browser). The
client only supports cipher suites in the possibly insecure category.
Instead of dropping the connection and letting the client display an for
a user not understandable generic message (e.g. “connection dropped, no
common cipher suites”), the server accepts the connection, but displays
a detailed warning and perhaps allows limited access to the data.

Now suppose the chosen cipher suite is insecure and an attacker can
perform an active MITM attack. Then the attacker can read the limited
data, which was already anticipated and is part of the risk model. On a
website the attacker can also prompt the user for credentials, which the
user will supply because she or he saw the padlock in the address bar
and thinks the connection is secure. This may nor may not work with
native applications (depends on the protocol).

If the TLS connection uses PKIX, the current PKIX system works, no
attacker can be issued a fake certificates and all cipher suites in the
possibly insecure category only include weak symmetric cryptographic
primitives, this attack could have been prevented by dropping the
connection when only cipher suites from the possibly insecure category
are available.

To summarise: I think the idea makes only sense for a few organisations.
The situations in which I would recommend to implement this idea are as
follows:

Your application has a client-server architecture. You run the server
and the server has all data. Interoperability with client software that
supports only cipher suites from the possibly insecure category is more
important than security to your organisation. You think that displaying
a warning message instead of dropping the connection is of great benefit
to your organisation (increased sales, fewer support calls), because too
many clients run software that only support possibly insecure cipher
suites, and a MITM attack is a low risk scenario for you (in comparison
to the benefits).

A typical example would be a retail company which fears decreased sales
if they don't support some older web browser version.

For everything else it makes little or no sense, especially if a user's
privacy is at risk or you run the server as a private person. I would
rather implement this directly in the web application instead of GnuTLS
(I can't think of a native application where you could display a
warning) and would be even stricter than GnuTLS is currently in all
other cases (only support high security cipher suites and key lengths
and TLS 1.2 or later etc.) instead of categorising cipher suites.

Regards,
Matthias-Christian