Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
UAG introduced few enhancements as part of the 2312 release for improved security.This document describes these security changes along with remediation steps to correct older settings and configurations.
ChangeReasonMitigation SHA-256 is the default minimum size of thumbprints for validation of server certificates during outbound TLS connections. SHA-1 is deprecated, MD5 is no longer supported. MD5 and SHA-1 hash algorithms are weak. UAG now enforces use of secure hash algorithms for certificate validation during outbound TLS connections. If any of the settings in UAG are configured with SHA-1 thumbprints, replace it with SHA-256, SHA-384 or SHA-512 thumbprints of the server certificate. When the URL thumbprint is not configured for outbound TLS connections, server certificate validation will now mandate hostname verification as per SAN/CN attribute in the server certificate, along with other PKI validations. Enforcing the hostname verification for outbound TLS connections prevents the possibility of Man-in-the-Middle (MITM) attacks. Use the thumbprint configuration on UAG to trust the server certificate OR Configure the remote server with a valid certificate intended for TLS server authentication and other appropriate attributes. Configure the remote server URL on UAG with a hostname that matches the SAN / CN attributes of the server certificate and relevant host entry if necessary. Validation of Host / X-Forwaded-Host headers in HTTP requests is enabled by default for Horizon and Web Reverse Proxy edge services and Admin REST APIs. This validation is done against allowed host header values configured by the administrator and a dynamically computed list of values based on UAG's network settings and edge service settings. These validations prevent any possibilities of Host header injection-based attacks on UAG and the services running behind it. Any IP or hostnames that are used for accessing the Unified Access Gateway directly or via load balancer or reverse proxy and not included in the auto allowed list should be configured in Allowed Host Headers field.
FAQs Deprecation of SHA-1 ThumbprintHostname Verification for Outbound TLS ConnectionsChanges in Host Header Validation Deprecation of SHA-1 Thumbprint SHA-1 Thumbprint deprecated How do I know this change impacts my UAG upgrade? Below are the settings that support thumbprint configuration for outbound TLS connection. If any of the below setting is configured with MD5 or SHA-1 thumbprints, same shall be updated. Connection Server URL thumbprint under Horizon Edge service settingsProxy Destination URL thumbprint under Web Reverse Proxy Edge service settingsOn-demand Agent download URL thumbprint under OPSWAT based Endpoint Compliance Check Provider settingsClient Custom Executable URL thumbprint under Client Custom Executable settingsPublic Key URL thumbprint under JWT settings (JWT Producer and JWT Consumer configurations)Workspace ONE Intelligence URL thumbprint under Workspace ONE Intelligence Connection Settings In the INI configuration used for UAG deployments, How do I mitigate the impact? If any of the configurations have SHA-1 thumbprints, replace it with SHA-256, SHA-384 or SHA-512 thumbprints of the server certificate. Note that, as of UAG 2312, the thumbprint hash algorithm will be identified based on the length of the provided text. With that change, algorithm prefix is optional now for any thumbprint. Example: Below are some samples of thumbprint configuration for Horizon or Web Reverse Proxy configuration in the INI configuration for Powershell based deployment of UAG. For other settings, key to be used for thumbprint configuration in the INI is 'urlThumbprints'. # This will be identified as SHA-256 as it has a length of 64 characters in hexadecimal format (excluding the separator) proxyDestinationUrlThumbprints=7E:XX:F4:XX:3C:5D:74:A7:A8:F0:CE:E1:9F:CA:63:99:64:A8:47:4E:7D:B5:0E:DE:8D:XX:2C:CB:XX:24:D3:XX # This will be identified as SHA-384 as it has a length of 96 characters in hexadecimal format proxyDestinationUrlThumbprints=0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264xxb47fb6bd1e058d5f004 # Or the thumbprint algorithm can be prefixed explicitly as well. proxyDestinationUrlThumbprints=sha384=0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264xxb47fb6bd1e058d5f004 Alternatively, if you want to continue using SHA-1 thumbprints, set the "Minimum SHA Hash Size" field under System Configuration to SHA-1 (not recommended). For powershell based deployment, 'minSHAHashSize' property can added under 'General' section of the ini file as shown below: [General] minSHAHashSize=SHA-1 How do I troubleshoot misconfigurations related to thumbprints? When an unsupported or incorrect thumbprint is provided, configuration or the functionality of the relevant setting will fail. Search for any of the below phrases in admin.log or esmanager.log files under /opt/vmware/gateway/logs folder. If you have matching results, you need to update the affected setting. # 1. Log statement with below phrase indicates that the thumbprint value does not match the algorithm prefix (example, sha256=invalid-sha256). Provided thumbprint does not match the hash algorithm given # 2. Log statement with below phrase indicates that the supplied thumbprint does not meet the minimum hash size criteria. thumbprints are not compatible with configured minimum hash size # 3. Any of the below phrases in logs indicate that a server certificate thumbprint does not match the configured value in UAG, hence failing the TLS connection Could not find a trusted certificate thumbprint that matches any of the server certificates due to mismatch in thumbprints. Unable to find valid certification path to requested target due to mismatch thumbprints Hostname Verification for Outbound TLS Connections Hostname Verification for Outbound TLS Connections How does this change impact my UAG upgrade? When the URL thumbprint is not configured, UAG now mandates hostname verification on the server certificate along with other PKI validations for successful outbound TLS connections. For a successful hostname verification, SAN (DNS or IP) attribute values in the server certificate should match the hostname in the URL configured on UAG. If SAN attribute is not available in the certificate, UAG will use the CN attribute value for the validation. How is it different from Extended Server Certificate Validation setting under System Configuration? Extended Server Certificate validation enables revocation status check on the server certificate chain in addition to the above validations. Extended Server Certificate validation is disabled by default. Which scenarios are impacted by this change? This change is applicable to outbound TLS connections initiated as part of the below settings. Horizon Edge Service SettingsWeb Reverse Proxy Edge Service SettingsJWT settings with public key URL configurationWorkspace ONE Connection SettingsOPSWAT based Endpoint Compliance Check Provider settingsClient Custom Executable URL under Client Custom Executable settings How do I mitigate the impact? There are two possible approaches to resolve this issue. Approach #1: Use Server Certificate Thumbprints Configure appropriate server certificate thumbprints in UAG to bypass above validations. Approach #2: Use Appropriate Certificate on the Remote Server, Matching Hostname in the URL on UAG Configure the remote server with a valid certificate intended for TLS server authentication and other appropriate attributes. Configure the remote server URL on UAG with hostname that matches the SAN / CN attributes of the server certificate. Relevant host entry might be required in case the hostname is not resolved via DNS. Example- Below are the excerpts from a sample INI configuration file for demonstration purpose. Before: Horizon proxy destination URL is configured with SHA-256 thumbprint - no change will be necessary in this configuration.Public key URL for JWT consumer configuration is configured with trusted certificate - this configuration should be updated with appropriate hostname or thumbprint. [Horizon] proxyDestinationUrl=https://10.x.x.100 proxyDestinationUrlThumbprints=7E:XX:F4:XX:3C:5D:74:A7:A8:F0:CE:E1:9F:CA:63:99:64:A8:47:4E:7D:B5:0E:DE:8D:XX:2C:CB:XX:24:D3:XX [JWTSettings1] issuer=JWT-Issuer jwtType=CONSUMER name=JWTConsumer1 url=https://10.x.x.110/broker/publicKey/protocolredirection publicKeyRefreshInterval=3600 trustedCert1=/path/to/cacert/ca1.pem After: Below changes have been done in the INI to ensure that the UAG will be functional on first boot. No change in Horizon edge service settings as it already uses thumbprints.Public key URL for JWT consumer configuration is updated with hostname that matches the server certificate.Appropriate host entry is configured under [Horizon] edge service settings. (If using Web Reverse Proxy, host entry can be configured under that as well) [Horizon] proxyDestinationUrl=https://10.x.x.100 proxyDestinationUrlThumbprints=7E:XX:F4:XX:3C:5D:74:A7:A8:F0:CE:E1:9F:CA:63:99:64:A8:47:4E:7D:B5:0E:DE:8D:XX:2C:CB:XX:24:D3:XX hostEntry1=10.x.x.110 jwt-host.hzn.example.com [JWTSettings1] issuer=JWT-Issuer jwtType=CONSUMER name=JWTConsumer1 url=https://jwt-host.hzn.example.com/broker/publicKey/protocolredirection publicKeyRefreshInterval=3600 trustedCert1=/path/to/cacert/ca1.pem Changes in Host Header Validation Changes in Host Header Validation How does this change impact my UAG upgrade? For Horizon or Web Reverse Proxy traffic, UAG validates Host or X-Forwarded-Host header in the request. X-Forwarded-Host header takes precedence over Host header, if available. Similarly, UAG validates the Host header for REST API requests on Admin service. These validations are done against two lists of allowed host headers: Allowed Host Headers - list of hostnames configured by the administrator.Auto-allowed Host Headers - dynamically computed list of allowed hostnames based on UAG's network settings and edge service settings. UAG's non-loopback IPs and internal hostname are included in this list and allowed by default.For Unified Access Gateway deployments with Horizon, if BSG and/or Tunnel are enabled and external URLs configured, these values will be included into auto allowed list. For Unified Access Gateway deployments with Web Reverse Proxy configurations, external URL and proxy host patterns are included into auto allowed list. When UAG is deployed with N+1 Virtual IP (VIP), the virtual IP is included into auto allowed list. If the UAG is accessed using a hostname / IP other than what is available in above two lists, the request will be rejected with HTTP 400 response status. Such a scenario can usually occur when An instance of UAG is fronted by another component like a load balancer, reverse proxy or another UAG. This component could add X-Forwaded-Host header in the request orproxy the original request without modifying HTTP headers - the original hostname corresponding to the load balancer will reach the UAG. The UAG is directly accessed by configuration of custom host entry or DNS CNAME configuration. How do I mitigate the impact? To mitigate the impact of this change, any IP or hostnames that are used for accessing the UAG directly or via load balancer or reverse proxy and not included in the auto allowed list should be configured in Allowed Host Headers field, as described below. When deploying UAG using Powershell scripts and INI configuration, use 'allowedHostHeaderValues' key to configure comma separated list of allowed values. [General] allowedHostHeaderValues=uag1.example.com,uag-lb.example.com Post deployment of UAG, this field can be updated with any of the below options: Using Admin UI Login into UAG Admin UI and click on 'Configure Manually' section. Locate 'Allowed Host Headers' under System Configuration and update as necessary. Save the changes. Using CLI Command Use 'adminreset' CLI command to update the allowed host header values as necessary. # Login to UAG root console # Run 'adminreset' command as below # adminreset --allowedHostHeader [comma-separated-list-of-allowed-hosts] adminreset --allowedHostHeader uag1.example.com,uag-lb.example.com My UAG is responding with HTTP 400, how do I troubleshoot? If UAG Admin UI / REST API is responding with HTTP 400 status, search for the below phrase in /opt/vmware/gateway/logs/admin.log. # Request is rejected by Admin service due to invalid hostname represented by <uag-hostname>. Configure this value in allowed host header list using 'adminreset' CLI. Rejecting request from <source>. The request was rejected because the domain <uag-hostname> is untrusted. If UAG is responding with HTTP 400 status for Horizon or Web Reverse Proxy traffic, search for below phrases in /opt/vmware/gateway/logs/esmanager.log. # 1. In the below log message, if XFH (X-Forwarded-Host) header value is present, that needs to be allowed on UAG. Otherwise, host header value needs to be allowed. UAGW00388: Sending bad request. Incoming request does not have valid host header: <host-header-value>, XFH: <xfh-header-value> # 2. This scenario occurs when UAG is accessed with HTTP protocol on port 80 with invalid hostname represented by <redirect-host> Redirect host <redirect-host> does not match the allowed hosts. Hence sending 400