Bug 1802606 - Cluster-wide proxy does not accept uppercase hostname
Summary: Cluster-wide proxy does not accept uppercase hostname
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.3.0
Hardware: All
OS: All
unspecified
medium
Target Milestone: ---
: 4.4.0
Assignee: Juan Luis de Sousa-Valadas
QA Contact: huirwang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-13 14:27 UTC by Gabriel Stein
Modified: 2020-05-04 11:36 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Using httpProxy or httpsProxy hostname with uppercases makes the the CNO fatal, which is a violation of RFC3986. Consequence: CNO won't work at all and as it's cluster-critical it has a major impact. Fix: Parse it with golangs url.ParseRequestURI, which implements RFC3986 correctly and a few more RFCs. Result: Capital case is now allowed in httpProxy and httpsProxy
Clone Of:
Environment:
Last Closed: 2020-05-04 11:36:24 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift cluster-network-operator pull 479 None closed Bug 1802606: pkg/util: Fix URI validation to modern standards 2020-10-01 11:24:08 UTC
Red Hat Knowledge Base (Solution) 4827221 None None None 2020-02-13 14:27:14 UTC
Red Hat Product Errata RHBA-2020:0581 None None None 2020-05-04 11:36:39 UTC

Description Gabriel Stein 2020-02-13 14:27:14 UTC
- Using httpProxy or httpsProxy hostname with uppercases , then validation fails and the setup from ingress operator will fail ( ConfigMap: trusted-ca) and the operator pods will not start

Error:

"message": "The configuration is invalid for proxy ‘cluster’ (invalid httpProxy URI: failed validating URI \“http://MYPROXY.EXAMPLE.COM:8080\“: invalid host: MYPROXY.EXAMPLE.COM). Use ’oc edit proxy.config.openshift.io'

Code where the error is: https://github.com/openshift/cluster-network-operator/blob/4b9efdc9add4ba27bdd30c20d7d22095ef8f3e1f/vendor/k8s.io/apimachinery/pkg/util/validation/validation.go#L116

Please let me know if you need more info.

Comment 1 Juan Luis de Sousa-Valadas 2020-02-17 10:16:06 UTC
As per RFC3986 this should be allowed:

https://tools.ietf.org/html/rfc3986#section-3.2.2
~~~
   The host subcomponent of authority is identified by an IP literal
   encapsulated within square brackets, an IPv4 address in dotted-
   decimal form, or a registered name.  The host subcomponent is case-
   insensitive.
~~~

I see we use a dns 1123 matcher

As per RFChttps://tools.ietf.org/html/rfc1123#page-13 
~~~
   2.1  Host Names and Numbers

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4].  One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit.  Host software MUST support this more liberal
      syntax.

      Host software MUST handle host names of up to 63 characters and
      SHOULD handle host names of up to 255 characters.

      Whenever a user inputs the identity of an Internet host, it SHOULD
      be possible to enter either (1) a host domain name or (2) an IP
      address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
      the string syntactically for a dotted-decimal number before
      looking it up in the Domain Name System.
~~~

And RFC 952 says:

https://tools.ietf.org/html/rfc952
~~~
   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
   sign (-), and period (.).  Note that periods are only allowed when
   they serve to delimit components of "domain style names". (See
   RFC-921, "Domain Name System Implementation Schedule", for
   background).  No blank or space characters are permitted as part of a
   name. No distinction is made between upper and lower case.
~~~

Now checking why this line is here, turns out what kubernetes calss DNS-1123 isn't actually RFC 1123: https://github.com/kubernetes/kubernetes/pull/39675

I believe this is a valid bug.

Comment 4 huirwang 2020-02-18 10:59:38 UTC
Hi Gabriel,

Could you let me know the steps how to reproduce the issue?

I tried to reproduce the issue in old version by below way. But I cannot reproduce it.
With "oc edit proxy.config.openshift.io", using httpProxy or httpsProxy hostname with uppercases, no error messages.

huiran-mac:script hrwang$ oc edit proxy.config.openshift.io
proxy.config.openshift.io/cluster edited

huiran-mac:script hrwang$ oc get proxy.config.openshift.io -o yaml
apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: Proxy
  metadata:
    creationTimestamp: "2020-02-17T01:37:21Z"
    generation: 3
    name: cluster
    resourceVersion: "719453"
    selfLink: /apis/config.openshift.io/v1/proxies/cluster
    uid: c000f406-f1b3-482b-b8a9-79c8200466ec
  spec:
    httpProxy: http://MYPROXY.EXAMPLE.COM:8080
    httpsProxy: http://MYPROXY.EXAMPLE.COM:8080
    trustedCA:
      name: ""
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Comment 6 huirwang 2020-02-19 05:53:02 UTC
Verified in 4.4.0-0.nightly-2020-02-18-200822

Comment 12 errata-xmlrpc 2020-05-04 11:36:24 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0581


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