Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: Add option to choose allowed TLS versions #5119

Closed
zdohnal opened this issue Sep 22, 2017 · 12 comments
Closed

RFE: Add option to choose allowed TLS versions #5119

zdohnal opened this issue Sep 22, 2017 · 12 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@zdohnal
Copy link
Contributor

zdohnal commented Sep 22, 2017

Hi,
I'm currently working on this RFE for our customer. Desired outcome will be similar like in mod_ssl module for httpd - cupsd could choose how strong ciphers will be used for encryption - options will be something like these: LOW-MEDIUM-HIGH.
Do you want to add this feature to CUPS, when I send the patch?

@michaelrsweet
Copy link
Collaborator

First, only one of the TLS libraries supported by CUPS (GNU TLS) offers this sort of support. The macOS security framework has very low level control (which we use in some cases) and the Windows security provider interface doesn’t allow applications any direct control. Both macOS and Windows limit supported ciphers by default to those that are either considered secure or are required for interoperability.

Second, the SSLOptions directive in client.conf and cupsd.conf already provides specific options to allow low security ciphers for interop (AllowRC4 and AllowDH) and deny cipher suites and versions that are being phased out (DenyCBC and DenyTLS1.0). Conceptually you could add generic “BestSecurity” and “BestCompatiblity” options, however I have my concerns about options that can change behaviour across releases.

But finally I have never liked these mod_ssl (really OpenSSL) options since the definitions of LOW, MEDIUM, and HIGH are not clear and vary not based on the application version but on the library version in use. All of the security focused guides therefore provide an explicit list of cipher suites and TLS versions and not the low, medium, or high pseudo settings.

The default for CUPS is a balance between compatibility and security.

@michaelrsweet
Copy link
Collaborator

So to answer your question, it will depend. Just supporting what mod_ssl does will be rejected. Doing something better will be considered.

@michaelrsweet michaelrsweet self-assigned this Sep 24, 2017
@michaelrsweet michaelrsweet added the question General usage question label Sep 24, 2017
@zdohnal
Copy link
Contributor Author

zdohnal commented Sep 25, 2017

Ciphers, which customer consider as medium strong, are part of TLS 1.0 and use CBC, so DenyCBC and DenyTLS1.0 should work. But what about TLS 1.1? It uses same ciphers as TLS 1.0 (that's how I understood it), so what about adding option DenyTLS1.1, which will make CUPS to use TLS 1.2?

@michaelrsweet michaelrsweet added enhancement New feature or request and removed question General usage question labels Sep 25, 2017
@michaelrsweet michaelrsweet added this to the CUPS 2.3.x Release milestone Sep 25, 2017
@michaelrsweet
Copy link
Collaborator

TLS 1.1 has other differences from TLS 1.0, and the set of ciphers is not generally limited by the TLS version (each TLS version has one or more required cipher suites, but any version can generally implement any cipher suite).

I can see maybe adding a DenyTLS1.1 directive, but perhaps for future proofing we should start using "MinTLS" options instead since TLS 1.3 is all but done and that syntax would be forward-looking.

@michaelrsweet michaelrsweet changed the title RFE: Add option to choose how strong ciphers will be used for encryption RFE: Add option to choose allowed TLS versions Sep 25, 2017
@zdohnal
Copy link
Contributor Author

zdohnal commented Sep 25, 2017

MinTLS directive sounds reasonable. Let's go with that.

@hardfalcon
Copy link
Contributor

hardfalcon commented Oct 16, 2017

@michaelrsweet:

First, only one of the TLS libraries supported by CUPS (GNU TLS) offers this sort of support. The macOS security framework has very low level control (which we use in some cases) and the Windows security provider interface doesn’t allow applications any direct control.

It seems this only applies to the old CryptoAPI on Windows. If you use "Cryptography API: Next Generation" (CNG), it seems to be possible to add and remove single ciphersuites for a connection without having to fiddle with the registry:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx
CNG is supported on Windows Vista / Server 2008 and newer.
I've never used neither CryptoAPI nor CNG myself, though.

@zdohnal
Copy link
Contributor Author

zdohnal commented Oct 23, 2017

Should MinTLS be complementary to SSLOption directive? Or can be there conflicts between these to directives? To sum it up - what relationship will MinTLS and SSLOptions have?
I created patch for cups in RHEL 7 for now, where cups is built with openssl. Patch introduces new option for SSLOption directive - DenyTLSv1.1, because I didn't know possible relations between SSLOption and MinTLS directives. When I will have time (at beginning of November), I can rewrite it for GNUTLS (I am not familiar of Mac or Windows encrypting libraries), if you are interested.

@michaelrsweet
Copy link
Collaborator

MinTLS will be an SSLOptions value, as an alternative to adding a bunch more DenyTLS#.# or AllowTLS#.# options.

@zdohnal
Copy link
Contributor Author

zdohnal commented Oct 23, 2017

So there will be SSLOptions values like MinTLS1.0, MinTLS1.1, MinTLS1.2, if I understood correctly?

@michaelrsweet
Copy link
Collaborator

Yes

@zdohnal
Copy link
Contributor Author

zdohnal commented Oct 23, 2017

Ok, thank you, Mike.

michaelrsweet pushed a commit that referenced this issue Nov 3, 2017
- cups/http-private.h: Move TLS/SSL version options to separate version
  constants, make _httpTLSSetOptions take min/max version numbers.
- cups/tls-*.c: Update _httpTLSSetOptions and _httpTLSStart to use new min/max
  version numbers.
- cups/tlscheck.c: Update _httpTLSSetOptions call.
- cups/usersys.c: Support new SSLOptions values, update _httpTLSSetOptions call.
- scheduler/conf.c: Support new SSLOptions values, update _httpTLSSetOptions
  calls.
@michaelrsweet
Copy link
Collaborator

[master 8f1fbde] Add support for MinTLS and MaxTLS options (Issue #5119)

michaelrsweet added a commit that referenced this issue Mar 7, 2018
- Fixed a compile issue when PAM is not available (Issue #5253)
- Documentation fixes (Issue #5252)
- Star Micronics printers need the "unidir" USB quirk rule (Issue #5251)
- The scheduler now supports using temporary print queues for older IPP/1.1 print queues like those shared by CUPS 1.3 and earlier (Issue #5241)
- The `cupsRasterWritePixels` function did not correctly swap bytes for some formats (Issue #5225)
- Added a USB quirk rule for Canon MP280 series printers (Issue #5221)
- The `ppdInstallableConflict` tested too many constraints (Issue #5213)
- More fixes for printing to old CUPS servers (Issue #5211)
- The `cupsCopyDest` function now correctly copies the `is_default` value (Issue #5208)
- The scheduler did not work with older versions of uClibc (Issue #5188)
- The scheduler now substitutes default values for invalid job attributes when running in "relaxed conformance" mode (Issue #5186)
- Fixed PAM module detection and added support for the common PAM definitions (Issue #5185)
- Fixed a journald support bug in the scheduler (Issue #5181)
- The cups-driverd program incorrectly stopped scanning PPDs as soon as a loop was seen (Issue #5170)
- Fixed group validation on OpenBSD (Issue #5166)
- Fixed the `ippserver` sample code when threading is disabled or unavailable (Issue #5154)
- The `cupsEnumDests` function did not include options from the lpoptions files (Issue #5144)
- The `SSLOptions` directive now supports `MinTLS` and `MaxTLS` options to control the minimum and maximum TLS versions that will be allowed, respectively (Issue #5119)
- The scheduler did not write out dirty configuration and state files if there were open client connections (Issue #5118)
- The `lpadmin` command now provides a better error message when an unsupported System V interface script is used (Issue #5111)
- The `lp` and `lpr` commands now provide better error messages when the default printer cannot be found (Issue #5096)
- No longer support backslash, question mark, or quotes in printer names (Issue #4966)
- The CUPS library now supports the latest HTTP Digest authentication specification including support for SHA-256 (Issue #4862)
- The `lpstat` command now reports when new jobs are being held (Issue #4761)
- The `lpoptions` command incorrectly saved default options (Issue #4717)
- The `ppdLocalizeIPPReason` function incorrectly returned a localized version of "none" (rdar://36566269)
- TLS connections now properly timeout (rdar://34938533)
- The IPP backend did not properly detect failed PDF prints (rdar://34055474)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants