diff --git a/architecture/index.adoc b/architecture/index.adoc
index cc92811c0fc6..5a287ab703ed 100644
--- a/architecture/index.adoc
+++ b/architecture/index.adoc
@@ -118,8 +118,9 @@ xref:additional_concepts/authentication.adoc#architecture-additional-concepts-au
 credentials, and then xref:additional_concepts/authorization.adoc#architecture-additional-concepts-authorization[authorize]
 them based on their role. Both developers and administrators can be
 authenticated via a number of means, primarily
-xref:additional_concepts/authentication.adoc#oauth[OAuth tokens] and SSL
-certificate authorization.
+xref:additional_concepts/authentication.adoc#oauth[OAuth tokens] and X.509
+client certificates. OAuth tokens are signed with JSON Web Algorithm
+_RS256_, which is RSA signature algorithm PKCS#1 v1.5 with SHA-256.
 
 Developers (clients of the system) typically make REST API calls from a
 xref:../cli_reference/index.adoc#cli-reference-index[client program] like `oc` or to the
@@ -138,7 +139,7 @@ checks for one or more of the roles assigned to the user (e.g., cluster
 administrator or administrator of the current project) before allowing it to
 continue.
 
-ifdef::openshift-origin,openshift-online,openshift-enterprise,openshift-dedicated[]
+ifdef::openshift-origin,openshift-online,openshift-enterprise[]
 Since every container that runs on the cluster is associated with a service
 account, it is also possible to associate
 xref:../dev_guide/secrets.adoc#dev-guide-secrets[secrets] to those service accounts and have them
@@ -146,3 +147,91 @@ automatically delivered into the container. This enables the infrastructure to
 manage secrets for pulling and pushing images, builds, and the deployment
 components, and also allows application code to easily leverage those secrets.
 endif::[]
+
+All communication channels with the REST API as well as between
+xref:infrastructure_components/kubernetes_infrastructure.adoc#master-components[master components]
+such as etcd and API server, are secured with
+link:https://en.wikipedia.org/wiki/Transport_Layer_Security[TLS]. TLS
+provides strong encryption, data integrity, and authentication of servers with
+X.509 server certificates and public key infrastructure.
+ifdef::openshift-origin,openshift-enterprise,openshift-dedicated[]
+By default, a new internal PKI is created for each deployment of {product-title}.
+xref:../install_config/certificate_customization.adoc#install-config-certificate-customization[Custom certificates]
+for public hosts are supported as well. The internal PKI uses 2048 bit RSA keys
+and SHA-256 signatures.
+endif::[]
+
+{product-title} uses Golang’s standard library implementation of crypto/tls and
+does not depend on any external crypto and TLS libraries link:https://golang.org/pkg/crypto/tls/[crypto/tls].
+Additionally the client depends on external libraries for GSSAPI authentication
+and OpenPGP signatures. GSSAPI is typically provided by either
+MIT Kerberos or Heimdal Kerberos, which both use OpenSSL's libcrypto. OpenPGP
+signature verification is handled by libgpgme and GnuPG.
+
+The insecure versions SSL 2.0 and SSL 3.0 are unsupported and not available.
+{product-title} server and `oc` client only provide TLS 1.2 by default. TLS
+1.0 and TLS 1.1 can be enabled in the server configuration. Both server and
+client prefer modern cipher suites with authenticated encryption algorithms
+and perfect forward secrecy. Cipher suites with deprecated and insecure algorithms
+such as RC4, 3DES, and MD5 are disabled. Some internal clients (e.g. LDAP authentication)
+have less restrict settings with TLS 1.0 to 1.2 and more cipher suites enabled.
+
+.Supported TLS versions
+[cols="4*", options="header"]
+|===
+|TLS version
+|{product-title} server
+|`oc` client
+|other clients
+
+|SSL 2.0
+|unsupported
+|unsupported
+|unsupported
+
+|SSL 3.0
+|unsupported
+|unsupported
+|unsupported
+
+|TLS 1.0
+|no footnoteref:[tlsconfig,Disabled by default, can be enabled in server config.]
+|no footnoteref:[tlsconfig]
+|_maybe_ footnoteref:[otherclient,some internal clients like LDAP client]
+
+|TLS 1.1
+|no footnoteref:[tlsconfig]
+|no footnoteref:[tlsconfig]
+|_maybe_ footnoteref:[otherclient]
+
+|TLS 1.2
+|*yes*
+|*yes*
+|*yes*
+
+|TLS 1.3
+|n/a footnoteref:[tls13,TLS 1.3 is still under development.]
+|n/a footnoteref:[tls13]
+|n/a footnoteref:[tls13]
+|===
+
+.Enabled cipher suites of {product-title} server and `oc` command
+
+The cipher suites list is sorted in preferred order.
+
+* TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
+* TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
+* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
+* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
+* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
+* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
+* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
+* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
+* TLS_RSA_WITH_AES_128_GCM_SHA256
+* TLS_RSA_WITH_AES_256_GCM_SHA384
+* TLS_RSA_WITH_AES_128_CBC_SHA
+* TLS_RSA_WITH_AES_256_CBC_SHA