Use SecureTLSConfig() everywhere

The function SecureTLSConfig() of the name github.com/openshift/origin/pkg/cmd/server/crypto is used in several places to set safe and sane default settings of crypto/tls.TLSConfig. The default TLS version is only 1.2 instead of TLS 1.0, 1.1, and 1.2. Since PR #15400 SecureTLSConfig() also disables cipher suites with 3DES.

A couple of places in Origin's code base do not use the function, for example https://github.com/openshift/origin/blob/master/pkg/auth/ldaputil/client.go#L21 and https://github.com/openshift/origin/blob/master/pkg/cmd/server/kubernetes/master/master_config.go#L514 . To make it easier to apply a common policy for TLS settings and to increase security, Origin should use SecureTLSConfig() all over the place.

In order to apply default settings to all tls.Config structs, some refactoring is required. Otherwise we'd end up with a dependency cycle between pkg/cmd/util and cmd/server/crypto. IMHO cmd/util/crypto.go is a good place for SecureTLSConfig() and a couple of other functions. After all the are used outside the cmd/server namespace or just used by SecureTLSConfig():

• TLSVersion
• ValidTLSVersions
• DefaultTLSVersion
• CipherSuite
• ValidCipherSuites
• DefaultCiphers
• SecureTLSConfig

I found out about the issue while I was working on https://github.com/openshift/openshift-docs/pull/4946 / https://trello.com/c/a9egV9TF/62-1-sccfsi-publicly-document-the-key-configurations-and-crypto-levels-in-openshifts-default-configuration

CC @openshift/sig-security

Start by reading pkg/auth/ldaputil/client.go and pkg/cmd/server/kubernetes/master/master_config.go, then trace SecureTLSConfig() and the TLS helper functions listed in the issue. Check the dependency relationship between pkg/cmd/util and cmd/server/crypto before planning the refactor. Done means the identified tls.Config construction sites use the shared secure defaults without introducing a dependency cycle.