Bug 1463976 - [oeP7vrTZ]The router pod will be crashed when the cipher is unvalued
[oeP7vrTZ]The router pod will be crashed when the cipher is unvalued
Status: CLOSED WONTFIX
Product: OpenShift Container Platform
Classification: Red Hat
Component: Routing (Show other bugs)
3.6.0
All All
medium Severity medium
: ---
: ---
Assigned To: Ben Bennett
zhaozhanqi
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-22 04:08 EDT by zhaozhanqi
Modified: 2017-06-22 07:16 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-22 07:16:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description zhaozhanqi 2017-06-22 04:08:39 EDT
Description of problem:
the haproxy pod will be crashed if setting the cipher is a unvalued which is NOT (modern,intermediate,old). So we should verify the value of ROUTER_CIPHERS

Version-Release number of selected component (if applicable):
oc v3.6.121
kubernetes v1.6.1+5115d708d7
features: Basic-Auth GSSAPI Kerberos SPNEGO


How reproducible:
always

Steps to Reproduce:
1. Create haproxy to make it running
2. update the cipher to invalud
  oc env dc ROUTER_CIPHERS=non
3. check the haproxy router pod

Actual results:

haproxy pod become 'CrashLoopBackOff'

Expected results:

should verify the value of ROUTER_CIPHERS to make it in [modern,intermediate,old]
Additional info:
Comment 1 Ben Bennett 2017-06-22 07:16:21 EDT
The ROUTER_CIPHERS can also take any SSL cipher suite (https://en.wikipedia.org/wiki/Cipher_suite).

Our named settings are just conveniences based on the current recommendations at https://wiki.mozilla.org/Security/Server_Side_TLS and we will update them as the recommendations change.

But people may want to specify a specific cipher suite, e.g.:

ECDHE+aRSA+AES256+GCM+SHA384:ECDHE+aRSA+AES128+GCM+SHA256:ECDHE+aRSA+AES256+SHA384:ECDHE+aRSA+AES128+SHA256:ECDHE+aRSA+RC4+SHA:ECDHE+aRSA+AES256+SHA:ECDHE+aRSA+AES128+SHA:AES256+GCM+SHA384:AES128+GCM+SHA256:AES128+SHA256:AES256+SHA256:DHE+aRSA+AES128+SHA:RC4+SHA:HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

And honestly, validating the valid settings doesn't seem worthwhile.  Admins will get these from their security teams, or from websites where there are recommendations.  They aren't likely to tweak these often.  So the admin will make a change and then (presumably) test the config and see the router is broken and fix it.  This is something only the router admin can set (and there are plenty of other environment variables they can set that will also break the router).

If we could allow this per-route, then we would absolutely need to stringently validate these, because a user could set an annotation that would crash a router.  However, it is not yet possible to per-route cipher negotiation yet.

Note You need to log in before you can comment on or make changes to this bug.