7016877: Configuring eDirectory to mint certificates with a SHA-2 signature

Digital signatures prove ownership. They provide proof that a user is in fact talking to the CA authority who signed a certificate and not some man-in-the-middle.

When encrypting data the public key is used to encrypt the data for the entity holding the private key. However, in this case the roles are reversed. A private key can be used to prove ownership of a public key. The holder of the private key encrypts a small amount of data with the private key then sends that data (in the clear) along with the encrypted data itself. The public key holder uses that key to decrypt the data and compare it to the token (unencrypted) data sent. Only the private key holder can send this type of data to verify its signature on the certificate. This token/encrypted data pair is called a digital signature. Digital signatures cannot effectively sign large amounts of data. Therefore, a hash function is used to take all the certificate variable data and reduce it to a digest containing a small fixed amount of data. This hash is then encrypted with the private key. The verification process afterward is thus:

– The signature is included along with the certificate

– The signature is decrypted with the public key to get the hash

– The certificate is then hashed with the same algorithm

– The two hashed values are then compared

There have been a number of prior hashing algorithms. As computational power increased, the possibility of reversing the hash in an acceptable amount of time has also increased. Prior to SHA-1 MD5 was used until a flaw was found in 2004. Since then SHA-1 has been used. Now the possibility of it also becoming compromised due to increased processing power has spurred the industry to adopt SHA-2.

In support of this major browser manaufacturers are taking steps to begin phasing out SHA-1 signed certificates. Many already are not allowing SHA-1 certificates if they are valid beyond January 2017 (the final cutoff date for support). Some vendors will not accept them past January 1, 2016.

Related:

  • No Related Posts

How Do I Configure HTTP Strict Transport Security (HSTS) on NetScaler

HSTS stands for HTTP Strict Transport Security. The main objective of HSTS is to protect websites against various attacks like SSL strip, Cookie Hijacking, Downgrade attack etc. RFC 6797 covers the exact IETF standardized functionality of HSTS. HSTS enables servers to declare to other entities (Web browsers, Applications etc) to communicate to the server only via HTTPS connection. This is done by web server by setting Strict-Transport-Security HTTP response header field.

NetScaler 12.0 appliances support HTTP strict transport security (HSTS) as an inbuilt option in SSL profiles and SSL virtual servers. For information on configuring this feature refer to CTX224172 – How to Enable HTTP Strict Transport Security (HSTS) on NetScaler 12.

Use Case

  • Ramesh wishes to interact with various web sites (some arbitrary, some known) in a secure fashion through a web browser.

  • Banking.com wishes to offer their site in an explicitly secure fashion for their own, as well as their users’, benefit.

Ramesh has user account in banking.com and is a regular user transacting through banking.com regularly. As usual Ramesh wants to transfer money to his friend and thus he accesses the website banking.com by typing URL www.banking.com.

User-added image

In this case, browser converts this to http://www.banking.com. Browser detects the name banking.com, communicates with DNS server and gets IP address for host server.

Browser contact the IP address received on port 80. The banking website sends a redirect request to https://www.banking.com. SSL handshake and certificate verification happens leading to SSL connection establishment. The padlock in URL bar will change to green and will be in locked state.

User-added image

User-added image
Ramesh can now enter his credentials safely to make the required transaction.

Well, what can go wrong now? A man in the middle can intercept the resolving request for banking.com and send Ramesh his own server ip address. When request is made to the IP address on port 80 he can redirect Ramesh to his own slightly mispronounced website https://www.blanking.com. Ramesh might not notice the change and enter his credentials thereby giving his details to someone else.

Other possibility is when intruder presents his own certificate for banking.com and this time browser identifies it is not a trusted certificate and sends a pop up asking Ramesh if he wants to override this warning. People , at times ignore warning messages and will end up falling in the trap of intruder.

How HSTS helps?

HSTS sends Strict-Transport-Security flag set in the HTTP response header field. It also sends a value in the header which denotes the time for which the browser can keep the website under STS sites.

HSTS prevents scenarios mentioned above by making sure that they respond only to https request and doesn’t allow Ramesh to override the warning. Also in recent browser versions when the browser receives a HTTP request for a website under STS list, it will automatically makes a HTTPS request to the server thus helping users to be protected from these attacks. This cool feature can be enabled in NetScaler enabling actual backend servers to have this protection through NetScaler path as we do SSL offloading on NetScaler.

Related:

  • No Related Posts

When won’t the SSLV be able to decrypt? Does the client and SSLV have to be integrated into a corporate Certificate Authority as with forward proxy so the SSLV can resign the traffic?¬

I do not need a solution (just sharing information)

Any Man-in-the-Middle (MITM) device that is going to inspect outbound SSL traffic (traffic to SSL servers not under the control of the enterprise) has to be a bump in the wire as it needs to intercept the SSL handshake messages from the server and modify the server certificate before it is sent to the client in order to gain access to the decrypted traffic. This is true for any MITM device providing visibility into outbound SSL traffic and is down to how the protocol works. The term that we use for the method used to inspect outbound traffic is Certificate Re-sign to reflect that SSLV, ProxySG or any other MITM needs to modify the original server certificate before it is sent to the client and this requires the use of a Certificate Authority that is part of the MITM device. In order for the client to not see warnings it needs to trust the Certificate Authority being used by the MITM device.

In the case of inbound SSL traffic from clients the enterprise does not control to SSL servers that the enterprise does control a different mechanism is used. This is what we call Known Server Key and it requires that SSLV (or any other MITM) has a copy of the SSL servers certificate and private key. Using KSK does not require that the client be modified or configured to trust any special Certificate Authorities. As long as the server certificate is for a publicly trusted server the client will not generate any warnings when SSLV carries out KSK to provide visibility.

0

Related:

  • No Related Posts

When won’t the SSLV be able to decrypt? Does the client and SSLV have to be integrated into a corporate Certificate Authority as with forward proxy so the SSLV can resign the traffic?

I do not need a solution (just sharing information)

Any Man-in-the-Middle (MITM) device that is going to inspect outbound SSL traffic (traffic to SSL servers not under the control of the enterprise) has to be a bump in the wire as it needs to intercept the SSL handshake messages from the server and modify the server certificate before it is sent to the client in order to gain access to the decrypted traffic. This is true for any MITM device providing visibility into outbound SSL traffic and is down to how the protocol works. The term that we use for the method used to inspect outbound traffic is Certificate Re-sign to reflect that SSLV, ProxySG or any other MITM needs to modify the original server certificate before it is sent to the client and this requires the use of a Certificate Authority that is part of the MITM device. In order for the client to not see warnings it needs to trust the Certificate Authority being used by the MITM device.

In the case of inbound SSL traffic from clients the enterprise does not control to SSL servers that the enterprise does control a different mechanism is used. This is what we call Known Server Key and it requires that SSLV (or any other MITM) has a copy of the SSL servers certificate and private key. Using KSK does not require that the client be modified or configured to trust any special Certificate Authorities. As long as the server certificate is for a publicly trusted server the client will not generate any warnings when SSLV carries out KSK to provide visibility.

0

Related:

  • No Related Posts

VU#767208: ThreatMetrix SDK for iOS fails to validate SSL certificates

Vulnerability Note VU#767208

ThreatMetrix SDK for iOS fails to validate SSL certificates

Original Release date: 10 Jan 2017 | Last revised: 11 Jan 2017

Overview

On the iOS platform, the ThreatMetrix SDK versions prior to 3.2 fail to validate SSL certificates provided by HTTPS connections, which may allow an attacker to perform a man-in-the-middle (MITM) attack.

Description

ThreatMetrix is a security library for mobile applications, which aims to provide fraud prevention and device identity capabilities. The ThreatMetrix SDK versions prior to 3.2 do not validate SSL certificates on the iOS platform. An affected application will communicate with https://h-sdk.online-metrix.net, regardless of whether the connection is secure or not.

Impact

An attacker on the same network as or upstream from the iOS device may be able to view or modify ThreatMetrix network traffic that should have been protected by HTTPS.

Solution

Apply an update

This issue has been addressed in ThreatMetrix SDK versions 3.2 and later. Any iOS application that uses a vulnerable version of the ThreatMetrix SDK will need to be regenerated with an updated version of the library.

Avoid untrusted networks

Avoid using untrusted networks, including public WiFi. Using your device on an untrusted network increases the chance of falling victim to a MITM attack.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
ThreatMetrix Affected 04 Jan 2017 10 Jan 2017

If you are a vendor and your product is affected, let
us know
.

CVSS Metrics (Learn More)

Group Score Vector
Base 4.8 AV:A/AC:L/Au:N/C:P/I:P/A:N
Temporal 4.0 E:F/RL:OF/RC:C
Environmental 3.9 CDP:ND/TD:ND/CR:ND/IR:ND/AR:ND

References

Credit

This vulnerability was reported by Will Dormann of the CERT/CC.

This document was written by Will Dormann.

Other Information

  • CVE IDs:
    CVE-2017-3182
  • Date Public:
    10 Jan 2017
  • Date First Published:
    10 Jan 2017
  • Date Last Updated:
    11 Jan 2017
  • Document Revision:
    11

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Related: