ADM and Director Intergration missing Network HDX data: Error “No details are available” or blank page

Running Citrix ADM 13.0 (latest) and attempting to integrated the network function into our Citrix Director 1912.

Attempted to use both HTTP and HTTPS.

WIth HTTP the network tab on director is blank.

With HTTPS it say no details are available.

The following guide was used: https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/director/hdx-insight.html

Using HTTPS ::

Using HTTPS

Network capture trace shows Director Servers sends a FIN and interrupt TLS Handshake with ADM Server.

TLS flow Request from ADM Server

==========================

Transport Layer Security

TLSv1.2 Record Layer: Handshake Protocol: New Session Ticket

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 170

Handshake Protocol: New Session Ticket

TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec

Content Type: Change Cipher Spec (20)

Version: TLS 1.2 (0x0303)

Length: 1

Change Cipher Spec Message

TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 96

Handshake Protocol: Encrypted Handshake Message

Response TLS from Director Server

==========================

Transmission Control Protocol, Src Port: 52282, Dst Port: 443, Seq: 342, Ack: 4300, Len: 0

Source Port: 52282

Destination Port: 443

[Stream index: 0]

[TCP Segment Len: 0]

Sequence Number: 342 (relative sequence number)

Sequence Number (raw): 1163837986

[Next Sequence Number: 343 (relative sequence number)]

Acknowledgment Number: 4300 (relative ack number)

Acknowledgment number (raw): 1444382645

0101 …. = Header Length: 20 bytes (5)

Flags: 0x011 (FIN, ACK)

Window: 512

[Calculated window size: 131072]

[Window size scaling factor: 256]

Checksum: 0xb928 [unverified]

[Checksum Status: Unverified]

Urgent Pointer: 0

[SEQ/ACK analysis]

[Timestamps]

When using HTTP :: Browser shows a blank page, no errors or details.

Related:

  • No Related Posts

ADM and Director Intergration missing Network HDX data :: Error “No details are available” or blank page

Running Citrix ADM 13.0 (latest) and attempting to integrated the network function into our Citrix Director 1912.

Attempted to use both HTTP and HTTPS.

WIth HTTP the network tab on director is blank.

With HTTPS it say no details are available.

The following guide was used: https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/director/hdx-insight.html

Using HTTPS ::

Using HTTPS

Network capture trace shows Director Servers sends a FIN and interrupt TLS Handshake with ADM Server.

TLS flow Request from ADM Server

==========================

Transport Layer Security

TLSv1.2 Record Layer: Handshake Protocol: New Session Ticket

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 170

Handshake Protocol: New Session Ticket

TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec

Content Type: Change Cipher Spec (20)

Version: TLS 1.2 (0x0303)

Length: 1

Change Cipher Spec Message

TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 96

Handshake Protocol: Encrypted Handshake Message

Response TLS from Director Server

==========================

Transmission Control Protocol, Src Port: 52282, Dst Port: 443, Seq: 342, Ack: 4300, Len: 0

Source Port: 52282

Destination Port: 443

[Stream index: 0]

[TCP Segment Len: 0]

Sequence Number: 342 (relative sequence number)

Sequence Number (raw): 1163837986

[Next Sequence Number: 343 (relative sequence number)]

Acknowledgment Number: 4300 (relative ack number)

Acknowledgment number (raw): 1444382645

0101 …. = Header Length: 20 bytes (5)

Flags: 0x011 (FIN, ACK)

Window: 512

[Calculated window size: 131072]

[Window size scaling factor: 256]

Checksum: 0xb928 [unverified]

[Checksum Status: Unverified]

Urgent Pointer: 0

[SEQ/ACK analysis]

[Timestamps]

When using HTTP :: Browser shows a blank page, no errors or details.

Related:

  • No Related Posts

How Do I Block SSLv2 on NetScaler?

This article describes how to block SSLv2 on NetScaler.

Note: According to RFC6176 from Internet Engineering Task Force (ITEF), TLS servers must not support SSLv2. The NetScaler appliance does not support SSLv2 from release 12.1.

Use Case

SSL v2 protocol has many security vulnerabilities which makes it essential for a user to disable it and opt for stronger and more secure protocols such as TLS v1.1 / v1.2.

Introduction to SSL v2

SSL v2 (SSL 2.0) is a protocol created by Netscape in 1994. It was identified with many security vulnerabilities many of which were later resolved in SSL v3, which as well is impacted by security vulnerabilities.

Here is a list of some of the flaws in SSL v2:

  1. SSL v2 has a weak MAC (message authentication code) construction which uses 40 bit of encryption in export mode. It uses the MD5 hash function which makes it vulnerable to length extension attacks wherein an attacker can delete bytes from the end of messages.
  2. It is vulnerable to cipher suite attack as the handshake messages are not protected. In this attack, the attacker edits the list of cipher suite preferences to a lower cipher suite without any detection (in the hello messages). This forces the client and server to agree upon a weaker form of encryption than they otherwise would have chosen.
  3. Message authentication and message encryption use the same key. This can lead to a problem if the client and server negotiate a weak encryption
  4. Session terminated can be forged. A man-in-the-middle attacker can easily insert a TCP FIN to terminate the session. The receiving endpoint is unable to determine whether it is a legitimate end of session request or not thus resulting in an unwanted termination.
  5. SSL v2 does not follow chain certificate and does not support non-RSA algorithm. It only supports RSA key exchange which may not be the preferred option in many cases
  6. SSL v2 only supports one domain certificate with a single service. This is not a preferable option as it would not support virtual hosting for web servers.

Related:

How Do I Setup TLS_FALLBACK_SCSV On NetScaler?

Use Case

Protect server against POODLE attack by preventing the protocol downgrade attack.

Introduction to TLS_FALLBACK_SCSV

POODLE attack is a man-in-the-middle attack in which an attacker takes advantage of the fall back behaviour of clients (including browsers) to attack servers which support SSL 3.0 and CBC encryption mode.

User-added image

Most SSL/TLS implementations are backward compatible with SSL 3.0 to interoperate with legacy systems. A POODLE attacker leverages the fact that when a secure connection attempt fails, servers will fall back to older protocols such as SSL 3.0. He can trigger a connection failure and then force the use of SSL 3.0 and attempt an attack.

User-added image

To mitigate the POODLE attack, one approach is to completely disable SSL 3.0 on the client side and the server side. However, some old clients and servers do not support TLS 1.0 and above, so disabling SSL 3.0 might not be possible. The solution to this problem is that the browsers and servers should implement TLS_FALLBACK_SCSV which makes downgrade attacks impossible. This is how it works – browsers support a downgrade mechanism in the form of Signaling Cipher Suite Value (SCSV). After a session fails during the initial handshake, the browser will retry, but attempts on version one lower than before. For example, after failing to connect to a server with the max version set to TLS 1.1, the client would retry with the max version set to TLS 1.0. This mechanism basically ensures connectivity but lowers down the security and makes the session vulnerable.

The presence of this SCSV extension in the Client Hello indicates that the client is retrying to connect to the server by using a lower SSL version, after its previous attempt to communicate with a higher version failed. Therefore, if the server finds this extension in Client Hello and also finds that the client is proposing a version that is lower than the maximum version supported by the server, it is a likely indication of a “man in the middle attack” The server drops such handshakes.

Qualys SSL Labs, which test servers and browsers for SSL vulnerabilities, mandates a server to support TLS_FALLBACK_SCSV to get A+ rating.

Related:

TLS handshake fails with any TLS LB VIP FIPS 9700 – Reset code 9811 from ADC

Daylight savings time changed and NTP Servers out-of sync with ADC.

Time mismatch between client-server created by Daylight saving time 2020 began at 2:00 AM Time stamp mismatch in client-server created by Daylight Saving time change and out-of sync NTP server.

TLS is time sensitive, ADC detects a time mismatch and teardown TLS Session sending a RESET with Code 9811

Note regarding REST code 9811

=============================

As part of TLS handshake :: After a “Change Cipher Spec” message from Client machine, ADC should send back another “Change Cipher Spec” confirming the newly created TLS Session, but instead ADC sends a RESET message with RESET code :: 9811 because it detected a time stamps mismatch.


Following this article :: NetScaler Reset Error Codes

https://support.citrix.com/article/CTX200852

Reset code 9811 means :: NSDBG_RST_ERRHANDLER: This reset code is used with SSL. After sending a Fatal Alert, the NetScaler sends a RST packet with this error code. If the client does not display any supported ciphers to the NetScaler appliance, the appliance sends a Fatal Alert and then this RST packet.

In this case this error code is deceiving because the client machine did displayed ciphers available to ADC, but ADC found a mismatch in Time Stamp TLS Session-ID and invalidates the Session.

Cipher used on this Session was :: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

Handshake Protocol: Server Hello

Handshake Type: Server Hello (2)

Length: 87

Version: TLS 1.2 (0x0303)

Random: 5e66690d10ed940e434f5ef414065933aac401eaf2806ad7…

Session ID Length: 32

Session ID: 1a1ff2f6e4aaa45336d6c8f3454892b324fea21528474cce…

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

Compression Method: null (0)

Extensions Length: 15

Extension: application_layer_protocol_negotiation (len=11)

Related:

Considerations for Upgrading from 12.0 to 12.1

1) Removal of Weak Ciphers from DEFAULT_BACKEND cipher Group

This should not cause any issues for customers with backend applications that use modern Ciphers and TLS.

However legacy applications may face connectivity issues if specific Cipher Groups, with these older Ciphers enabled, are not configured.

Make sure to check if any backend Web Server/Resource/Application requires the above Ciphers before upgrade.

If they do, configure a Cipher Group with the required Ciphers and bind this to the Service or Service Group and unbind the DEFAULT_BACKEND Cipher Group.


2) Change in Password Encryption for Private Keys/Certificate-Key Pairs

Support for KEK encryption in private key

The password of the private key used while adding an SSL certificate-key pair is now saved using a unique encryption key for each Citrix ADC appliance.

For more information, see https://docs.citrix.com/en-us/netscaler/12-1/ssl/config-ssloffloading.html#add-or-update-a-certificate-key-pair.

Important: Certificate keys are lost if you downgrade to a build earlier than release 12.1 build 50.x.

[From Build 50.31]

[# NSHELP-14911]

https://www.citrix.com/content/dam/citrix/en_us/documents/downloads/netscaler-adc/Citrix-ADC-12-1-54-16.html

Customers should not see any issues with this change during the upgrade.

However if they do need to downgrade back for any reason, all their encrypted Private keys will not be added during the downgrade.

To get around this, you can either do 1 of 2 things:

1: (Recommended) Take a backup of the configuration while on 12.0, so if a downgrade is needed, a restore can be performed after the downgrade

–or–

2: Do not save the configuration after the upgrade to 12.1 until it has been confirmed that everything is working and there is no need to downgrade.

Related:

  • No Related Posts

Overview of the Crypto Kit updates in Citrix Workspace 1904

Applicable Products

Citrix Workspace App 1904 for Windows and later.

Objective

This feature is an important change to the secure communication protocol. Cipher suites with the prefix TLS_RSA_ do not offer forward secrecy and are considered weak. These cipher suites were deprecated in Citrix Receiver version 13.10 with an option for backward compatibility.

In this release, the TLS_RSA_ cipher suites have been removed entirely. Instead, this release supports the advanced TLS_ECDHE_RSA_ cipher suites. If your environment is not configured with the TLS_ECDHE_RSA_ cipher suites, client launches are not supported due to weak ciphers.

This document aims to detail the changes to the cipher suites.

What’s New?

The following advanced cipher suites are supported:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

In earlier releases, the GPO configuration that was available under the below Computer Configuration node which allowed to enable the deprecated cipher suites has been removed now.

Administrative Template > Citrix Component > Citrix Workspace > Network Routing > Deprecated Cipher Suites


The following cipher matrix provides the ciphers supported by the latest SSL SDK:

Expected failure scenarios and edge cases

  • TCP

    • OPEN mode: Session launch is not supported when the client is configured for GOV and the VDA for COM. This happens because a common cipher suite is absent.

    • FIPS/NIST(SP800-52) compliance mode: Session launch is not supported when the VDA is configured for COM the client for COM, GOV, or ANY, or the other way around. This happens because a common cipher suite is absent.
  • DTLS v1.0 supports the following cipher suites:
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_EMPTY_RENEGOTIATION_INFO_SCSV
  • DTLS v1.2 supports the following cipher suites:
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    • TLS_EMPTY_RENEGOTIATION_INFO_SCSV
  • Therefore, session launch is not supported from a client configured for GOV to a VDA configured for COM. Also, fallback to TCP is not supported. When you use DTLS v1.0, session launch is not supported for clients configured for GOV because a common cipher suite is absent.

.

The following matrices provide details of internal and external network connections:

  • Matrix for internal network connections (Citrix Gateway scenario)

  • Matrix for external network connections (Citrix Gateway scenario)

Note: When NetScaler Gateway is used

  1. For the EDT to work, NetScaler Gateway must be of version 12.1 or higher since the older versions doesn’t support ECDHE cipher suites in DTLS mode.

  2. NetScaler Gateway doesn’t support DTLS 1.2 so TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 are not supported and NetScaler Gateway must be configured to use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA for it to work in DTLS 1.0

Related:

Client Authentication Certificate or Mutual TLS Support for Older Bluecoat Version

I need a solution

Hi,

Can anyone tell me if Blueoat version 6.5.10.12 supports Mutual TLS or a Client Authentication certificate? Basically we have a system that will make a restful web service call to our MuleSoft implementation using Mutual TLS or a client certificate to authenticate the request but the HTTP request is made from the client system to the Bluecoat 6.5.10.12 system then to the Mulesoft on-premisis instance. We need the Bluecoat to potentially handle the SSL handshake to secure the “wire” between the client system and the Bluecoat but we want to pass the client certificate through to Mulesoft. We would like to also have a TLS endpoint exposed from MuleSoft so the whole transmission is encrypted. Can this be done with any of these products? Specifically, we would like like to know if this version supports this or we should upgrade to the latest version of ProxySG which we believe, based on technical documents, does support this. Anything that you can contribute would be appeciated.

Thanks.

0

Related:

  • No Related Posts

Secure Mail iOS 19.3.5 and Secure Mail Android 19.6.5 Not Able to Create Account or Connection Error

Before users can create an account in Secure Mail for iOS version 19.3.5 or Secure Mail Android 19.6.5, you must do the following:

1. On Citrix ADC, the following cipher suite value must be added in the SSL Ciphers option: – ECDHE-RSA-AES256-GCM-SHA384.

Note: If the ciphers are already bound, go to step 2.

For details, see https://docs.citrix.com/en-us/netscaler/12/ssl/ciphers-available-on-the-citrix-ADC-appliances/configure-user-defined-cipher-groups-on-the-adc-appliance.html


2. Bind Enable Elliptical Curve Cryptography (ECC).

For details, see ECDSA cipher suites support in the Citrix ADC 12.1 documentation https://docs.citrix.com/en-us/citrix-adc/12-1/ssl/ciphers-available-on-the-citrix-ADC-appliances/ecdhe-ciphers.html.

For FIPS enabled environments, verify that the RSA key size for identity certificate (i.e. server certificate), intermediate certificates, and your root certificate are 2048 or 3072 bits. We do not currently support an RSA key size of 4096 bits in a FIPS-enabled environment . The new crypto library checks for key size and will reject the connection.

For configuration information see the following Citrix support article: https://support.citrix.com/article/CTX205289

Related: