Understanding ECC Certificates
Public-key cryptography is a cryptographic system that requires a secret key and a public key that are mathematically linked with each other. One key encrypts the plain text while the other decrypts the cipher text. RSA is the most widely used public-key algorithm.
Elliptic Curve Cryptography (ECC) were introduced as an alternative to RSA in public key cryptography. One advantage of ECC over RSA is key size versus strength. For example, a security strength of 80 bits can be achieved through an ECC key size of 160 bits, whereas RSA requires a key size of 1024. With a 112-bit strength, the ECC key size is 224 bits and the RSA key size is 2048 bits.
The most popular signature scheme that uses elliptic curves is called the Elliptic Curve Digital Signature Algorithm (ECDSA). The most popular key agreement scheme is called Elliptic Curve Diffie-Hellman (ECDH). An ECDH exchange is a variant of the Diffie-Hellman (DH) protocol and is an integral part of the Suite B cryptography standards proposed by the National Security Agency (NSA) for protecting both classified and unclassified information.
About Suite B
The Advanced Encryption Standard (AES) is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST) in 2001. Because a single encryption algorithm cannot satisfy all of the needs of the national security community, NSA created a larger set of cryptographic algorithms, called Suite B, which can be used along with AES in systems used by national security users. In addition to AES, Suite B includes cryptographic algorithms for hashing, digital signatures, and key exchanges.
Per RFC 6460, to be Suite B TLS 1.2 compliant the server and client should negotiate with the following ciphers:
•TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
•TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
RFC 6460 also lists a transitional Suite B profile for TLS 1.0 and TLS 1.1. Clients and servers that do not yet support Suite B TLS 1.2 should negotiate with the following ciphers:
•TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
•TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
There is no special configuration to ensure that Ivanti Connect Secure and Policy Secure negotiates Suite B ciphers. However, the following general steps should be performed to enable Suite B compliance:
•An ECC certificate signed by an ECC Root CA is associated with a network port.
•A P-256 CSR is signed by either a P-256 or P-384 Root CA.
•A P-384 CSR is be signed by a P-384 Root CA.
•Manually enable only AES128 and/or AES256 custom ciphers.
Using ECC Certificates
ECC certificates are currently supported only on the ISA Series Gateways and virtual appliance platforms. As with RSA certificates, ECC certificates are associated with a network port. You can create multiple virtual ports on the server with each port supporting a specific certificate. For example, external virtual port 1 can use a 1024-bit RSA while external virtual port 2 uses ECC P-256 and external virtual port 3 uses ECC P-384. Only clients that support ECC cipher suites can connect to the web server on that network port.
When an Elliptic Curve Cryptography (ECC) certificate is associated with a network port, only clients that support ECC cipher suites can connect to the Web server on that network port.
Except for the key and certificate generation process, the use of ECC certificates is basically the same as using RSA certificates.
Example: Assigning an ECC P-256 Certificate to an External Virtual Port and Giving Preference to Suite B Ciphers
This example outlines the general steps for creating an external port and assigning an ECC P-256 certificate. The steps are generally the same as assigning an RSA certificate to a port.
•Configuring the External Port
•(optional) Configuring the Virtual Ports
•Creating the Certificate Signing Request for a New Certificate
•Importing the Signed Certificate Created from a CSR
•Presenting the Certificate on the Network
Configuring the External Port
The external port handles all requests from users signed into the server from outside the customer LAN, for example, from the Internet.
To configure the external port:
1.In the admin GUI, choose System > Network > External Port > Settings.
2.Modify the settings as needed. In this example, only IPv4 is enabled. See the following figure.
Configuring the External Port for IPv4
3.Click Save Changes.
(optional) Configuring the Virtual Ports
A virtual port is an IP alias bound to a physical port. It shares all of the network settings, except IP address, with the associated physical port. You can use virtual ports for different purposes, depending on the physical port or the VLAN on which you base the virtual port. In this example, we are configuring the virtual port on the external port to support external sign-ins. This is an optional step that shows one way of allowing multiple certificates on the device.
To configure the external virtual port:
1.In the admin GUI, choose System > Network > External Port > Virtual Ports.
2.Click New Port.
In this example, the port is named p_ecdsa256 and accepts only IPv4 addresses. See the following figure Creating the Virtual Port on the External Port.
Creating the Virtual Port on the External Port
3.Click Save Changes.
Creating the Certificate Signing Request for a New Certificate
A certificate signing request (CSR) is a message sent from an applicant to a certificate authority (CA) to apply for a digital identity certificate. You create a CSR through the admin console. When you create a CSR, a private key is created locally that corresponds to the CSR. If you delete the CSR at any point, the private key is deleted too, prohibiting you from installing a signed certificate generated from the CSR.
In this example, a CSR for an ECC P-256 certificate is requested.
To create a CSR for a new certificate:
1.In the admin console, choose System > Configuration > Certificates > Device Certificates.
2.Click New CSR.
3.Enter the required requestor information. In this example, the common name is ecc-p256.pulsesecure.net.
4.Click ECC and select P-256 from the ECC Curve menu. See the following figure.
Creating an ECC P-256 Certificate Signing Request
5.Click Create CSR. A CSR is successfully created, as shown in the following figure.
6.The CSR is encoded and can be copied or saved to a file. The ECC certificate should be signed by an ECC CA for Suite B compliance. Follow your CA's process for sending a CSR.
7.Click the Back to Device Certificates link. Until you import the signed certificate from your CA, your CSR is listed as Pending. See Figure Pending CSR.
Importing the Signed Certificate Created from a CSR
Once your CA has sent your signed certificate, you must import that into the pending CSR.
To import a signed device certificate created from a CSR:
1.In the admin console, choose System > Configuration > Certificates > Device Certificates.
2.Under Certificate Signing Requests, click the Pending CSR link that corresponds to the signed certificate. See the above Pending CSR figure.
3.Under Import signed certificate, browse to the certificate file you received from the CA and then click Import. See the above CSR Successfully Created figure.
Presenting the Certificate on the Network
You can present a certificate many ways, depending on your configuration. For example, you can present the certificate to one or more virtual ports or on an internal or external port. In this example, the ECC P-256 certificate is presented on the external virtual port p1.
To present a certificate on an external virtual port:
1.In the admin console, select System > Configuration > Certificates > Device Certificates.
2.Click the certificate name you want to assign to a port. In this example, click ecc-p256.pulsesecure.net.
3.Under External Ports, select p_ecdsa256 and click Add. See the following figure.
Associating the ECC P-256 with the External Virtual Port p_ecdsa256
4.Click Save Changes.
Setting the Security Options
To specify the cipher suites for the incoming connection to the Web server, use the SSL Options page and select the Custom SSL Cipher Selection option. This step is required in our example to give Suite B cipher suites preference. If you do not want to give Suite B cipher suites preference, you do not have to perform this step.
Only when FIPS mode is turned on, the FIPS compliant ciphers are available to be chosen from the Supported Ciphers panel. FIPS mode is editable only on the inbound option page.
To set the security options with Inbound SSL Options:
1.In the admin console, select System > Configuration > Security > Inbound SSL Options.
2.Under Allowed Encryption Strength choose Custom SSL Cipher Selection. See the following Setting Custom SSL Cipher Selections figure.
Setting Custom SSL Cipher Selections
3.The two panels of Supported Ciphers and Selected Ciphers are displayed. Supported ciphers has the entire list of ciphers supported for the selected SSL or TLS version. Selected ciphers list the currently selected ciphers list. The below figure shows the two panels (Supported Ciphers and Selected Ciphers). Note that the Selected Ciphers and Supported Ciphers List will also be displayed for all Preset like PFS or SuiteB or Medium or High.
Supported Ciphers and Selected Ciphers Panels
4.To add a cipher to be used in order to secure a connection, click on the cipher string on the left panel and then click on the Add> or double click on the cipher name in the left panel. See the Setting Custom SSL Cipher Selections figure underneath.
5.To remove the cipher, click on the cipher name on the right panel and then click on the <Remove button or double click on the cipher name on the right side. See the Setting Custom SSL Cipher Selections figure underneath.
6.The selected ciphers on the right are listed in order of their priority from top to bottom. To change the priority of the ciphers, click on the cipher name and then click on Move Up to increase priority or the Move Down button to decrease the priority. See the Setting Custom SSL Cipher Selections figure underneath.
Setting Custom SSL Cipher Selections
7.If you are using client certificate authentication (Ivanti Connect Secure only):
•Select Enable client certificate on the external port under ActiveSync Client Certificate Configuration. See the ActiveSync Client Certificate Configuration figureunderneath.
•Move p_ecdsa256 to the Selected Virtual Ports column.
ActiveSync Client Certificate Configuration
8.Click Save Changes.
A list of the custom ciphers to be used on the device's port is displayed in the order the web server will select them. Note that Suite B ciphers are listed on top. See Confirming Custom Ciphers figureunderneath. End users who now log in to external virtual port p_ecdsa256 must have at least one of the listed ciphers installed on their browser or else they cannot log in to the server.
9.Click Change Allowed Encryption Strength.
- When custom ciphers are selected, there is a possibility that some ciphers are not supported by the web browser. Also, if any of ECDH/ECDSA ciphers are selected, they require ECC certificate to be mapped to the internal/external interface. If ECC certificate is not installed, admin may not be able to log in to the box. The only way to recover from this situation is to connect to the system console and select option 8 to reset the SSL settings from the console menu. Option 8 resets the SSL settings to its default. So, the previously set SSL settings are lost. This is applicable only to Inbound SSL settings.
- Pulse Mobile client will not be able to connect to ICS device, if the ciphers selected in Inbound option are not supported by the mobile client.
Enabling Outbound SSL Options
Only for Outbound SSL Settings, we can configure Non FIPS Ciphers when FIPS is Enabled using Custom Cipher Selection Option. Now, there are options to change different SSL/TLS versions and different encryptions in the Outbound SSL Settings. Outbound SSL Settingsshows the Outbound SSL Settings.
Verifying the Certificate on the Client
End users can check which certificate their browser is using to connect to the server. In the following example, the end user connects to server port p3, which uses an ECC curve P-256 certificate. See the following figure.
Connecting to a Port Using an ECC Curve P-256 Certificate
To view the certificate from an Internet Explorer 8 browser:
1.Open an Internet Explorer 8 browser and point to the server to which you want to connect.
2.Click the lock icon located at the end of the address bar and then click the View Certificate link. See the following figure.
Viewing the Connection Certificate Information
3.Click the Details tab and scroll down until you see the Public key field. In this example, the public key value is ECC (256 Bits) which matches the server port p3 certificate shown in the following figure.
Using TCP Dump to View Cipher Information
You can use the TCP Dump tool to view which cipher each client uses to connect to the server. TCP Dump is a packet analyzer that intercepts (sniffs) and displays TCP/IP and other packets transmitted or received between the server and clients.
To permit debugging, it is recommended that the ECC certificate be replaced by an RSA certificate so that an RSA cipher suite gets selected and then the application data can be decoded.
To capture packet headers:
1.Select Maintenance > Troubleshooting > Tools > TCP Dump.
2.Select the interface, internal or external or both, you wish to sniff and then the VLAN port.
3.Click Start Sniffing.
The next time a user points a browser window to the server or logs in to the server, handshake information is obtained.
4.Click Stop Sniffing when done.
To view the packet headers:
1.Select Maintenance > Troubleshooting > Tools > TCP Dump.
2.Under Dump file, select SSLDump from the file menu and the certificate to use. See the figureunderneath.
The certificate names in the TCP Dump window are the same as the "Certificate issued to" names in the Device Certificates window. Select the certificate corresponding to the port you wish to view packet information.
Issued to Certificate on the Device Certificates Pages
3.Click Get.
Portions of a TCP dump output follow.
The client starts a handshake with the server:
1 1 0.0007 (0.0007) C>S Handshake
The client then lists its supported cipher suites:
cipher suites
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_SHA
TLS_ECDH_ECDSA_WITH_DES_CBC3_SHA
...
The server acknowledges the handshake:
1 2 0.0010 (0.0003) S>C Handshake
The server compares the cipher suites on the client with the ones on the server and picks the cipher suite that is preferred by the server based on SSL options:
cipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
Example TCP Dump Output
New TCP connection #1: 10.64.8.3(46200) <-> 10.64.90.21(443)
1 1 0.0007 (0.0007) C>S Handshake
ClientHello
Version 3.3
cipher suites
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_SHA
TLS_ECDH_ECDSA_WITH_DES_CBC3_SHA
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_SHA
Unknown value 0xc001
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
compression methods
NULL
ClientHello Extensions [113]=
00 6f 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32
00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a
00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04
00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10
00 11 00 23 00 00 00 0d 00 22 00 20 06 01 06 02
06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01
03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 01
01
1 2 0.0010 (0.0003) S>C Handshake
ServerHello
Version 3.3
session_id[32]=
a3 07 40 6e 73 12 c2 4d f3 7d b9 77 f8 97 e1 94
fc 1b 51 6a 66 3c 99 d6 c7 7d 0e fa 29 2e d0 c4
cipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
compressionMethod NULL
ServerHello Extensions [20]=
00 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00
0f 00 01 01
1 3 0.0010 (0.0000) S>C Handshake
Certificate
1 4 0.0010 (0.0000) S>C Handshake
ServerHelloDone
1 5 0.1413 (0.1403) C>S Handshake
ClientKeyExchange
1 6 0.1413 (0.0000) C>S ChangeCipherSpec
1 7 0.1413 (0.0000) C>S Handshake
1 8 0.1464 (0.0051) S>C ChangeCipherSpec
1 9 0.1464 (0.0000) S>C Handshake
1 10 9.2389 (9.0924) C>S application_data
1 11 9.5828 (0.3438) C>S application_data
1 12 9.5833 (0.0004) S>C application_data
1 9.5833 (0.0000) S>C TCP FIN
1 13 9.5999 (0.0166) C>S Alert
1 9.5999 (0.0000) C>S TCP FIN
