Fixes panic on round tripper when TLS under a proxy

[fabianofranz]

@ncdc PTAL. I'll open upstream if it makes sense.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1336337
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1323666

[fabianofranz]

[test]

[ncdc]

I don't think this will make things any worse 😉

There needs to be a corresponding upstream pull to Kube and then this needs to turn into an UPSTREAM commit

[ncdc]

@liggitt

[fabianofranz]

@ncdc updated to UPSTREAM PR kubernetes/kubernetes#25690.

[openshift-bot]

Evaluated for origin test up to 5c8e213

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/3861/)

[liggitt]

LGTM, would like a test. Did you sweep the generic proxy handler to make sure a similar fix is not needed?

[fabianofranz]

@liggitt @ncdc Unfortunately I don't think this can be properly tested. I'd need a certificate from a trusted authority here, so that I could set clientTLS to nil in the test case to test if it would trust based on the system (instead of having to provide a RootCA). Do you foresee any other strategy?

[liggitt]

I actually meant expecting an error rather than a panic

[fabianofranz]

@liggitt Of course. You have to set clientTLS to nil in the test case to simulate this condition. It happens when you have a valid cert authority (so no explicit cert provided by config, nor insecure).

[fabianofranz]

[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5947/) (Image: devenv-rhel7_4238)

[openshift-bot]

Evaluated for origin merge up to 5c8e213