SSL Modification

[Ryan Holliday]

> Ryan Holliday wrote:
> > In refrence to http://www.cups.org/newsgroups.php?s16046+gcups.general+v16046+T0
> >
> > Since I have a working solution that involves a code change, I'm posting it here instead of in the orriginal thread.
> >
> > The problem turned out to be an issue with the interoperability between Windows and OpenSSL using the DES-CBC3-SHA cipher. Fortunatly OpenSSL has a workaround using the SSL_CTX_set_options() to pass through a SSL_OP_ALL flag. I got cups working by modifying two files and adding a line in order to set the options(I'm using CUPS 1.3.7):
> >
> > cups/http.c line 2706
> > SSL_CTX_set_options(context, SSL_OP_ALL);
> >
> > scheduler/client.c line 2948
> > SSL_CTX_set_options(context, SSL_OP_ALL);
> >
> >
> > The problem is SS_OP_ALL sets about 10 flags that could have a negative security impact on the cupsd daemon. I need to going through each flag to narrow down the combination of options that needs to be set for this to work. In addition, setting this flag should probably be configurable in the cupsd.conf file, and should not be enabled by default.
>
> We probably want to have CUPS+OpenSSL work with Windows in this mode,
> so if we can I'd like to make it the default mode.
>
> Once you figure out the minimum set of options required, please file a
> bug report here:
>
>      http://www.cups.org/str.php
>
> Thanks!
>
> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products           mike at easysw dot com

I submitted a bug report, but I'm posting the description and rationale here so that way it's not duplicated all over the place.

I narrowed down the OpenSSL setting that needs to be added to the CUPS code in order to correct the interoperability issue (SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS). This is problematic, however, because making this change can open CUPS up to a security vulnerability. http://eprint.iacr.org/2004/111.pdf

The issue as I understand it is the CBC cipher requires an Initialization Vector (IV) for each SSL message in order to encrypt the message. The IV is supposed to be some random number, and a fresh random number should be chosen for each message in a pure crypto environment. If the contents of the IV is known then an attacker "guess" at the contents of the packet and be able to know if the their guess is correct or not. This would leave the message open to a brute force attack to determine the contents of the message. The example in the paper says that a 8 digit pin can be obtain in about 10,000 tries.

The problem is the RFC specification for SSL 3.0 and TLS 1.0 says to only uses a random IV for the first message of the session, and each further IV is determined from the previous messages data. So if an attacker were able to insert a SSL message before the application sends it's message, then it would know the IV of the next message and it may be possible for them to decrypt a small nugget of information from the application message. The OpenSSL community devised a workaround that didn't violate the RFC standard but managed to fix this problem. They insert an empty SSL fragment before each message so that the attacker can not know the IV for the next message. This is enabled by default. http://www.openssl.org/~bodo/tls-cbc.txt

The problem came up because the Microsoft implementation of SSL/TLS rejects empty fragments which causes the entire SSL connection to break. This only happens when specific set of ciphers are used between the server and client. Typically they negotiate other ciphers, but when the FIPS compliance setting is checked Windows is forced to use it's broken cipher. By setting that flag in CUPS, you keep OpenSSL from inserting empty fragments before the message, which then raises the security concern.

According to the paper, in order to pull this attack off you would need some sort of browser plug-in or Trojan Horse in order to insert the SSL message into the connection. CUPS does not use a browser to send print jobs, so a plug-in should have no interaction with the print software. In addition, this attack would only be feasible for small nuggets of information such as a password or PIN number, but larger nuggets of information, such as entire print jobs, becomes prohibitive to decrypt.


Given that fixing one security vulnerability opens another, we had to determine which vulnerability posed the least amount of risk. For our DOD customer we determined that adding the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS into CUPS was the better solution. However, that might not hold true to all situations, especially for sites that do not require their Windows clients to use FIPS capability. I would recommend that this option be configurable in the cupsd.conf file so that sites can make their own determination on the security risks posed to their site.