HP A 5120 Manual

							 
241 
SSL configuration 
SSL overview 
Secure  Sockets  Layer  (SSL)  is  a  security  protocol that provides secure  connection  services for  TCP-based 
application  layer  protocols, such  as HTTP.  It  is  widely  used  in  E-business  and  online  banking to ensure 
secure data transmission over the Internet.  
SSL security mechanism 
Secure connections provided by SSL have these features: 
 Confidentiality—SSL uses a symmetric encryption algorithm to encrypt data and uses the asymmetric 
key  algorithm of Rivest,  Shamir,  and  Adelman (RSA)  to  encrypt the  key to  be  used  by  the symmetric 
encryption algorithm. 
 Authentication—SSL supports certificate-based  identity authentication of the server  and  client by 
using  the  digital  signatures. The SSL server  and  client obtain  certificates  from  a  certificate  authority 
(CA) through the Public Key Infrastructure (PKI). 
 Reliability—SSL  uses the key-based  message  authentication  code  (MAC)  to  verify  message  integrity. 
A MAC  algorithm transforms a  message of  any  length  to  a  fixed-length  message.  With  the  key,  the 
sender  uses  the  MAC  algorithm  to  compute  the  MAC  value  of  a  message.  Then,  the  sender  suffixes 
the  MAC  value  to  the  message  and  sends  the  result  to  the  receiver.  The receiver uses  the  same  key 
and MAC  algorithm  to  compute  the  MAC  value  of  the  received  message,  and  compares  the  locally 
computed MAC value with that received. If the two values match, the receiver considers the message 
intact;  otherwise,  the  receiver  considers that the  message has  been tampered with  in  transit and 
discards the message. 
Figure 72 Message integrity verification by a MAC algorithm 
 
 
 NOTE: 
 For more information about symmetric key algorithms, asymmetric key algorithm RSA and digital signature, see 
the chapter “Public key configuration.“ 
 For more information about PKI, certificate, and CA, see the chapter “PKI configuration.“  Key
Message
Sender
Message
Send to the receiver
MAC
KeyReceiver
Compare
MessageCompute the MAC
Compute the MAC MAC
MAC  
						

							 
242 
SSL protocol stack 
The SSL protocol consists of two layers of protocols: the SSL record protocol at the lower layer and the SSL 
handshake protocol, change cipher spec protocol, and alert protocol at the upper layer. 
Figure 73 SSL protocol stack 
 
 
 SSL  record  protocol—Fragments data  to  be  transmitted, computes and  adds MAC  to  the  data,  and 
encrypts the data before transmitting it to the peer end. 
 SSL  handshake  protocol—A  very  important  part  of  the  SSL  protocol  stack,  responsible  for 
negotiating the cipher suite to be used for secure communication (including the symmetric encryption 
algorithm, key  exchange  algorithm,  and  MAC algorithm),  securely  exchanging  the  key  between  the 
server and client, and implementing identity authentication of the server and client. Through the SSL 
handshake protocol, a session is established between a client and the server. A session consists of a 
set of parameters, including the session ID, peer certificate, cipher suite, and master secret. 
 SSL change  cipher  spec  protocol—Used  for  notification  between the client  and  the  server  that  the 
subsequent  packets  are  to  be  protected  and  transmitted based  on  the  newly  negotiated  cipher  suite 
and key. 
 SSL alert protocol—Enables the SSL client and server to send alert messages to each other. An alert 
message contains the alert severity level and a description. 
SSL configuration task list 
Complete the following tasks to configure SSL: 
Task Remarks 
Configuring an SSL server policy Required 
Configuring an SSL client policy Optional 
 
Configuring an SSL server policy 
An SSL server policy is a set of SSL parameters for a server to use when booting up. An SSL server policy 
takes effect only after it is associated with an application layer protocol such as HTTP. 
Configuration prerequisites 
Configure the PKI  domain for  the SSL  server  policy to  use  to obtain  the  server  side  certificate. For more 
information about PKI domain configuration, see the chapter ―PKI configuration.― Application layer protocol (e.g. HTTP)
TCP
IP
SSL handshake protocolSSL change cipher spec protocolSSL alert protocol
SSL record protocol  
						

							 
243 
Configuration procedure 
Follow these steps to configure an SSL server policy: 
To do... Use the command... Remarks 
Enter system view system-view — 
Create an SSL server policy and 
enter its view ssl server-policy policy-name Required 
Specify a PKI domain for the SSL 
server policy pki-domain domain-name 
Required 
By default, no PKI domain is 
specified for an SSL server policy. 
Specify the cipher suite(s) for the 
SSL server policy to support 
ciphersuite [ 
rsa_3des_ede_cbc_sha | 
rsa_aes_128_cbc_sha | 
rsa_aes_256_cbc_sha | 
rsa_des_cbc_sha | 
rsa_rc4_128_md5 | 
rsa_rc4_128_sha ] * 
Optional 
By default, an SSL server policy 
supports all cipher suites. 
Set the handshake timeout time 
for the SSL server handshake timeout time Optional 
3,600 seconds by default 
Set the SSL connection close 
mode close-mode wait Optional 
Not wait by default 
Set the maximum number of 
cached sessions and the caching 
timeout time 
session { cachesize size | timeout 
time } * 
Optional 
The defaults are as follows: 
 500 for the maximum number 
of cached sessions, 
 3600 seconds for the caching 
timeout time. 
Enable certificate-based SSL client 
authentication client-verify enable Optional 
Not enabled by default 
 
 NOTE: 
 If you enable client authentication here, you must request a local certificate for the client. 
 SSL mainly comes in these versions: SSL 2.0, SSL 3.0, and TLS 1.0, where TLS 1.0 corresponds to SSL 3.1. When 
the device acts as an SSL server, it can communicate with clients running SSL 3.0 or TLS 1.0, and can identify 
Hello packets from clients running SSL 2.0. If a client running SSL 2.0 also supports SSL 3.0 or TLS 1.0 
(information about supported versions is carried in the packet that the client sends to the server), the server will 
notify the client to use SSL 3.0 or TLS 1.0 to communicate with the server.  
SSL server policy configuration example 
Network requirements 
As  shown  in Figure  74,  users  can  access  and  control  the  device  through  web  pages.  For  security  of  the 
device,  users  must  use  HTTPS  (HTTP Secure,  which  uses  SSL)  to  log  in  to  the  web  interface  of  the  device 
and use SSL for identity authentication to ensure that data will not be eavesdropped or tampered with. 
To achieve the goal, perform the following configurations:  
						

							 
244 
 Configure Device to work as the HTTPS server and request a certificate for Device. 
 Request a certificate for Host so that Device can authenticate the identity of Host. 
 Configure a CA server to issue certificates to Device and Host.   
 NOTE: 
 In this example, Windows Server works as the CA server and the Simple Certificate Enrollment Protocol (SCEP) 
plug-in is installed on the CA server.  
 Before performing the following configurations, ensure that the device, the host, and the CA server can reach 
each other.  
Figure 74 Network diagram for SSL server policy configuration 
 
 
Configuration procedure 
1. Configure the HTTPS server (Device) 
#  Create  a  PKI  entity  named en, and configure  the  common  name  as http-server1 and the  FQDN  as 
ssl.security.com. 
 system-view 
[Device] pki entity en 
[Device-pki-entity-en] common-name http-server1 
[Device-pki-entity-en] fqdn ssl.security.com 
[Device-pki-entity-en] quit 
#  Create  PKI  domain 1, specify  the trusted CA as ca  server,  the  URL  of  the registration server  as 
http://10.1.2.2/certsrv/mscep/mscep.dll,  the authority  for certificate  request as  RA, and the entity for 
certificate request as en. 
[Device] pki domain 1 
[Device-pki-domain-1] ca identifier ca server 
[Device-pki-domain-1] certificate request url http://10.1.2.2/certsrv/mscep/mscep.dll 
[Device-pki-domain-1] certificate request from ra 
[Device-pki-domain-1] certificate request entity en 
[Device-pki-domain-1] quit 
# Create the local RSA key pairs.  
[Device] public-key local create rsa 
# Retrieve the CA certificate.  
[Device] pki retrieval-certificate ca domain 1 
# Request a local certificate for Device. 
[Device] pki request-certificate domain 1     10.1.1.1/2410.1.2.1/24
HostCA
10.1.1.2/2410.1.2.2/24
Device          
						

							 
245 
# Create an SSL server policy named myssl.  
[Device] ssl server-policy myssl 
# Specify the PKI domain for the SSL server policy as 1.  
[Device-ssl-server-policy-myssl] pki-domain 1 
# Enable client authentication.  
[Device-ssl-server-policy-myssl] client-verify enable 
[Device-ssl-server-policy-myssl] quit 
# Configure HTTPS service to use SSL server policy myssl. 
[Device] ip https ssl-server-policy myssl 
# Enable HTTPS service. 
[Device] ip https enable 
# Create a local user named usera, and set the password to 123 and service type to telnet. 
[Device] local-user usera 
[Device-luser-usera] password simple 123 
[Device-luser-usera] service-type telnet 
2. Configure the HTTPS client (Host) 
On  Host,  launch  IE,  enter http://10.1.2.2/certsrv in  the address  bar  and  request  a certificate  for  Host as 
prompted. 
3. Verify your configuration 
Launch IE on the host, enter https://10.1.1.1 in the address bar, and select the certificate issued by the CA 
server. The web interface of the device should appear. After entering username usera and password 123, 
you should be able to log in to the web interface to access and manage the device.  
 NOTE: 
 For more information about PKI configuration commands and the public-key local create rsa command, see the 
Security Command Reference.  
 For more information about HTTPS, see the Fundamentals Configuration Guide.  
Configuring an SSL client policy 
An  SSL  client  policy  is  a  set  of  SSL  parameters  for  a  client  to  use  when  connecting  to  the  server.  An  SSL 
client policy takes effect only after it is associated with an application layer protocol. 
Configuration prerequisites 
If the SSL server is configured to authenticate the SSL client, you must configure the PKI domain for the SSL 
client  policy to  use  to  obtain  the  certificate  of  the  client.  For more  information about  PKI  domain 
configuration, see the chapter ―PKI configuration.― 
Configuration procedure 
Follow these steps to configure an SSL client policy: 
To do… Use the command… Remarks 
Enter system view system-view —  
						

							 
246 
To do… Use the command… Remarks 
Create an SSL client policy and 
enter its view ssl client-policy policy-name Required 
Specify a PKI domain for the SSL 
client policy pki-domain domain-name 
Optional 
No PKI domain is configured by 
default.  
Specify the preferred cipher suite 
for the SSL client policy 
prefer-cipher { 
rsa_3des_ede_cbc_sha | 
rsa_aes_128_cbc_sha | 
rsa_aes_256_cbc_sha | 
rsa_des_cbc_sha | 
rsa_rc4_128_md5 | 
rsa_rc4_128_sha } 
Optional 
rsa_rc4_128_md5 by default 
Specify the SSL protocol version 
for the SSL client policy version { ssl3.0 | tls1.0 } Optional 
TLS 1.0 by default 
Enable certificate-based SSL 
server authentication server-verify enable Optional 
Enabled by default 
 
 NOTE: 
If you enable client authentication on the server, you must request a local certificate for the client.  
Displaying and maintaining SSL 
To do… Use the command… Remarks 
Display SSL server policy 
information  
display ssl server-policy { policy-
name | all } [ | { begin | exclude 
| include } regular-expression ] Available in any view 
Display SSL client policy 
information 
display ssl client-policy { policy-
name | all } [ | { begin | exclude 
| include } regular-expression ]  
 
Troubleshooting SSL 
SSL handshake failure 
Symptom 
As the SSL server, the device fails to handshake with the SSL client. 
Analysis 
SSL handshake failure may result from the following causes: 
 The SSL client is configured to authenticate the SSL server, but the SSL server has no certificate or the 
certificate is not trusted. 
 The SSL server is configured to authenticate the SSL client, but the SSL client has no certificate or the 
certificate is not trusted.  
						

							 
247 
 The server and the client have no matching cipher suite. 
Solution 
1. Issue the debugging ssl command and view the debugging information to locate the problem: 
 If the  SSL  client  is  configured  to  authenticate  the  SSL  server  but the  SSL  server  has  no  certificate, 
request one for it. 
 If  the  server’s certificate  cannot  be  trusted,  install the root  certificate of  the  CA that issued the  local 
certificate  to  the  SSL  server on  the  SSL  client,  or  let  the  server request a  certificate  from  the  CA that 
the SSL client trusts. 
 If the SSL server  is configured to  authenticate  the  client,  but  the SSL  client  has  no certificate  or the 
certificate cannot be trusted, request and install a certificate for the client. 
2. Use the display ssl server-policy command to view the cipher suites that the SSL server policy 
supports. If the server and the client have no matching cipher suite, use the ciphersuite command to 
modify the cipher suite configuration of the SSL server. 
  
						

							 
248 
TCP attack protection configuration 
TCP attack protection overview 
An attacker can attack the switch during the process of establishing a TCP connection. To prevent such an 
attack, the switch provides the SYN Cookie feature. 
Enabling the SYN cookie feature 
As a general rule, the establishment of a TCP connection involves the following three handshakes. 
1. The request originator sends a SYN message to the target server. 
2. After receiving the SYN message, the target server establishes a TCP connection in the 
SYN_RECEIVED state, returns a SYN ACK message to the originator, and waits for a response. 
3. After receiving the SYN ACK message, the originator returns an ACK message, establishing the 
TCP connection. 
Attackers may mount SYN Flood attacks during TCP connection establishment. They send a large number 
of SYN  messages  to  the  server  to establish TCP  connections, but  they  never  make  any  response  to  SYN 
ACK  messages.  As  a  result,  a  large number of incomplete TCP  connections  are  established,  resulting  in 
heavy resource consumption and making the server unable to handle services normally. 
The  SYN  Cookie  feature  can  prevent  SYN  Flood  attacks.  After  receiving  a  TCP  connection  request,  the 
server  directly  returns  a  SYN  ACK  message,  instead  of  establishing  an  incomplete TCP  connection.  Only 
after receiving an ACK message from the client can the server establish a connection, and then enter the 
ESTABLISHED  state.  In  this  way, incomplete TCP  connections  could  be  avoided  to  protect the  server 
against SYN Flood attacks. 
Follow these steps to enable the SYN Cookie feature: 
To do... Use the command... Remarks 
Enter system view system-view — 
Enable the SYN Cookie feature tcp syn-cookie enable Required 
Enabled by default. 
 
 NOTE: 
With the SYN Cookie feature enabled, only the MSS, is negotiated during TCP connection 
establishment, instead of the window’s zoom factor and timestamp.  
Displaying and maintaining TCP attack protection 
To do… Use the command… Remarks 
Display current TCP connection state display tcp status [ | { begin | exclude | 
include } regular-expression ]  Available in any view 
  
						

							 
249 
IP source guard configuration 
IP source guard overview 
Introduction to IP source guard 
IP source guard is  intended to  work  on  a  port  connecting  users.  It filters received packets to block illegal 
access  to network  resources,  improving network security. For  example,  it  can  prevent  illegal hosts  from 
using a legal IP address to access the network. 
IP source guard can filter packets according to the packet source IP address, and source MAC address. It 
supports these types of binding entries: 
 IP-port binding entry 
 MAC-port binding entry 
 IP-MAC-port binding entry 
After  receiving  a  packet, an  IP  source  guard-enabled  port  obtains the  key  attributes  (source IP  address, 
and source MAC address) of the packet and then looks them up in the binding entries of IP source guard. 
If  there  is  a  match,  the  port  forwards  the  packet; otherwise,  the  port  discards  the  packet,  as  shown  in 
Figure 75. IP source guard binding entries are on a per-port basis. After a binding entry is configured on 
a port, it is effective only on the port. 
Figure 75 Diagram for the IP source guard function 
 
 
IP source guard binding 
An IP source guard binding entry can be static or dynamic. 
Static IP source guard binding 
A  static  IP  source  guard  binding entry is  configured  manually.  It  is  suitable  for scenarios where  only  few 
hosts exist on  a  LAN  and their IP  addresses  are  manually  configured. For  example, you  can configure  a 
static  binding  entry  on  a  port  that  connects  a  server,  allowing  the  port  to  receive  packets  from  and  send 
packets to only the server.  
1. Types of static IP source guard binding entries 
According to the IP version, a static IP source guard binding entry is an IPv4 or IPv6 entry. IP network
Illegal host
Legal host
Enable the IP source guard function on 
the port for user access  
						

							 
250 
 A  static  IPv4  source  guard  binding entry  filters IPv4  packets received by  the  port  or  checks the 
validity of users by cooperating with the ARP detection feature.  
 A  static  IPv6  source  guard  binding entry  filters IPv6  packets  received  by  the  port  or  checks the 
validity of users by cooperating with the ND detection feature.   
 NOTE: 
 For information about ARP detection, see the chapter “ARP attack protection configuration.”  
 For information about ND detection, see the chapter “ND attack defense configuration.”  
2. Validity ranges of static IP source guard binding entries 
According  to the validity  range, a static  IP  source  guard  binding  entry is  a global or  port-based static 
binding entry: 
 A  global  static  binding  entry  is effective  on  all  ports.  A  port  forwards  a  packet  only  when  the 
packet’s  IP  address  and  MAC  address  both  matches  those  in  a  global  static  binding  entry or  both 
do  not  match  those  in any global  static  binding  entry.  If only the  IP  address  or  MAC  address  of  the 
packet matches  that  of a  global  static  binding  entry,  the  port  discards  the  packet.  Global  static 
binding  entries  are  used  to  protect  against  host  spoofing  attacks.  They  can  effectively  filter attack 
packets that exploit the IP address or MAC address of a legal user host.  
 A  port-based  static  binding  entry  is effective  on  only  the specified port.  A  port  forwards  a  packet 
only  when  the  IP  address, and MAC  address  of  the  packet  all  match  those  in  a  static  binding  entry 
on  the  port. All  other  packets  will  be  dropped.  Port-based  static  binding  entries  are  used  to  check 
the validity of users that are trying to access a port.  
 NOTE: 
Global static IP source guard binding entries take effect on all ports. However, port-based static IP 
source guard binding entries and dynamic IP source guard binding entries take precedence over global 
static IP source guard binding entries. If a port is configured with a static binding entry or dynamic 
binding, the global static binding entries do not take effect on the port.  
3. Excluded ports of global static binding entries 
In  some  circumstances,  global  static  binding entries may  result  in  communication  failures on  some  ports. 
In  such  cases,  specify  the  ports  as  excluded  ports,  so  that  global  static  binding  entries do  not take  effect 
on these ports. 
As shown in Figure 77, Device B is an access layer device connected to hosts of different VLANs. Device 
A works at the distribution layer as a gateway to allow hosts in different VLANs to communicate at Layer 
3.  When  a  host  in  a  VLAN communicates with a  host  in  another  VLAN, Device  A  forwards IP  packets 
between the VLANs, changing the source MAC addresses of the IP packets. For example, when Device A 
receives  an  IP  packet  from Host  A to Host  B, it  changes the  source  MAC  address  of the IP  packet from 
0001-0203-0406  to  0001-0202-0202,  its  own MAC  address.  If you  configure  a global  static  binding 
entry with Host A’s IP address and MAC address, Device B will drop the packets because the packets’  IP 
address  matches  the  entry  but  their  source MAC address  does  not  match  the  entry, preventing hosts  in 
different VLANs from communicating at Layer 3. 
To solve the problem, specify the uplink port (GE1/0/1) of Device B as an excluded port for global static 
binding.  Then,  the  global  static  binding  entry  does  not  take  effect  on  the  uplink  port, and packets 
forwarded by Device A will be forwarded normally.