Bug 1369865 - Non-SSL routes should not serve certificate content.
Summary: Non-SSL routes should not serve certificate content.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE
Version: 3.2.1
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: ---
Assignee: Phil Cameron
QA Contact: Yan Du
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-24 14:47 UTC by Eric Rich
Modified: 2021-12-10 14:43 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: suppresses use of the default certificate. Adds oc adm router--strict-sni option and ROUTER_STRICT_SNI environment variable. When set, default cert is not used. Reason: Result:
Clone Of:
Environment:
Last Closed: 2017-08-16 19:37:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Eric Rich 2016-08-24 14:47:54 UTC
Description of problem:

With the default certificate for *.somwildcarddomain.com on a routers the certificate is presented when non SSL enabled routes are accessed. 

> Example: a custom domain accessible only via http://mycustomdomain.com and not https. 

Invoking https://mycustomdomain.com returns a 503 error presenting the default certificate. We do not want that certificate to be presented. Instead, we want the connection to be closed.

The root issue her is that we, on port 443, setup a proxy https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L118-L121, that does not terminate SSL. Instead we use this as a generic endpoint to proxy to multiple (dynamic) SSL terminated proxy's, housed in the router, and it not until we hit these proxies and "server a certificate" that we then check for the existences of routes that meet the condition we want to route on.  

Version-Release number of selected component (if applicable): 3.2
How reproducible: 100% 

Additional info: 

The errors seems to be caused because we default to passing the SSL connections to the non SNI (edge termination backend), if requests are accessed on the 443 port. 

It seems as thought this (issue) could be fixed, by: 

> 1: First checking if a ssl mapping exists [0], and then defaulting to the openshift_default backend [1]. Requires a check like [2] for non-sni routes. 

[0] (if in [0.1] and not in [0.2])
  [0.1] https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L469-L475
  [0.2] https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L477-L551

[1] https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L212-L462
[2] https://github.com/openshift/origin/blob/master/images/router/haproxy/conf/haproxy-config.template#L123-L126

Comment 1 Ben Bennett 2016-08-24 17:49:09 UTC
The current behavior is intended.  Any traffic that hits the router on ports 80 or 443 (or whatever you configured the ports to) gets a response.  So, since the traffic came in on port 443, but there was no secure route that matched the request, we send back an HTTP 503 response to say that there is no matching service.

However, your complaint is that we are leaking certificate information that gives information out about the secure hosts.  I assume you don't want to put the cert in each of the tls routes you create.

You might be best off using a custom template for now:
  https://docs.openshift.com/enterprise/3.2/install_config/install/deploy_router.html#using-configmap-replace-template

(But watch out, the 3.3 template may change incompatibly, so keep the original template so you can see your changes)

It looks like you are asking for a way to say if a route doesn't match, don't return 503, but instead drop the connection?

Comment 3 Ben Bennett 2016-10-28 16:51:17 UTC
Since this is not a regression, we will try to get to it, but may not in 3.4.

Comment 4 Maru Newby 2016-12-14 22:44:53 UTC
Why is this showing up as a blocker?

Comment 5 Ben Bennett 2017-01-27 16:30:22 UTC
We are unlikely to make this change... it feels like bad policy to do this in general.  If the user wants to change the configuration of the router themselves they can replace the built-in config with a slightly customized version that does this:
  https://docs.openshift.com/container-platform/3.3/install_config/router/customized_haproxy_router.html

Comment 8 Phil Cameron 2017-06-14 17:22:32 UTC
origin PR 14621
https://github.com/openshift/origin/pull/14621

Comment 9 openshift-github-bot 2017-06-16 10:14:12 UTC
Commit pushed to master at https://github.com/openshift/origin

https://github.com/openshift/origin/commit/e8638ae594a7668805e2489198ceaabea8d05c6c
Donot serve certificate content for Non-SSL routes

By default, when a host does not resolve to a route in a HTTPS or tls
sni request, the default cert is returned to the caller as part of the
503 response. This exposes the default cert and may pose security
concerns. Haproxy strict-sni option to bind suppresses use of the
default cert.

This adds a new environment variable to the router deployment controller,
ROUTER_STRICT_SNI, to control bind processing. When set to "true" or
"TRUE", "strict-sni" is added to the bind. Default is "false".

oc adm router --strict-sni sets ROUTER_STRICT_SNI="true"

bug 1369865
https://bugzilla.redhat.com/show_bug.cgi?id=1369865

Comment 10 Phil Cameron 2017-06-16 17:53:35 UTC
openshift-docs PR 45955
https://github.com/openshift/openshift-docs/pull/4595

Comment 11 Phil Cameron 2017-06-19 15:04:29 UTC
Docs PR is 4595  (ignore the extra 5 at the end in comment 10

Comment 12 openshift-github-bot 2017-06-20 14:07:08 UTC
Commit pushed to master at https://github.com/openshift/openshift-docs

https://github.com/openshift/openshift-docs/commit/d12fee251045692aceacd7796e032078fe8f5c29
Do not serve certificate content for Non-SSL routes

Openshift 3.6

By default, when a host does not resolve to a route in a HTTPS or tls
sni request, the default cert is returned to the caller as part of the
503 response. This exposes the default cert and may pose security
concerns. Haproxy strict-sni option to bind suppresses use of the
default cert.

This adds a new environment variable to the router deployment
controller, ROUTER_STRICT_SNI, to control bind processing. When set
to "true" or "TRUE", "strict-sni" is added to the bind. Default
is "false".

oc adm router --strict-sni

sets ROUTER_STRICT_SNI="true"

origin PR 14621
https://github.com/openshift/origin/pull/14621

bug 1369865
https://bugzilla.redhat.com/show_bug.cgi?id=1369865

Comment 13 Yan Du 2017-06-29 09:11:43 UTC
Test on latest OCP 3.6.126.1, ROUTER_STRICT_SNI works well,could not get the serve certificate content for no-ssl routes when enable ROUTER_STRICT_SNI.

Comment 15 Yan Du 2017-07-05 08:30:01 UTC
Test on latest OCP-3.6, ROUTER_STRICT_SNI works well.
openshift v3.6.133
kubernetes v1.6.1+5115d708d7
etcd 3.2.1


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