HTTPS (full name: Hypertext Transfer Protocol over Secure Socket Layer) is a secure HTTP channel, in short, a secure version of HTTP. That is, the SSL layer is added under HTTP, and the security foundation of HTTPS is SSL. Therefore, please refer to SSL for details of encryption.
It is a URI scheme (abstract identifier scheme) with a syntax similar to the http: scheme. For secure HTTP data transfer. The https: URL indicates that it uses HTTP, but HTTPS has a different default port than HTTP and an encryption/authentication layer (between HTTP and TCP). Originally developed by Netscape, the system provides authentication and encrypted communication methods, and is now widely used for secure and sensitive communications on the World Wide Web, such as transaction payments.
It was developed by Netscape and built into its browser to compress and decompress data and return the results sent back over the network. HTTPS actually uses Netscape's Secure Sockets Layer (SSL) as a sublayer of the HTTP application layer. (HTTPS uses port 443, not port 80 as HTTP does to communicate with TCP/IP.) SSL uses a 40-bit key for the RC4 stream encryption algorithm, which is suitable for encrypting business information. HTTPS and SSL support the use of X.509 digital authentication, and the user can confirm who the sender is if needed.
That is to say, its main functions can be divided into two types: one is to establish an information security channel to ensure the security of data transmission; the other is to confirm the authenticity of the website.
Limitations
Its security protection depends on the correct implementation of the browser and the support of the server software and the actual encryption algorithm.
A common misconception is that "bank users can use https: online to fully protect their bank card numbers from being stolen." In fact, the encrypted connection to the server that protects the bank card number is only the user-to-server communication. connection and the server itself. There is no absolute guarantee that the server itself is secure, and this has even been exploited by attackers, a common example being a phishing attack imitating a bank's domain name. A few rare attacks occur when a website transmits customer data, and attackers try to grab the data in transit.
Commercial sites are expected to introduce new special handlers to financial gateways quickly and early, keeping only the transaction number. But they often store bank card numbers in the same database. Those databases and servers can be attacked and compromised by unauthorized users in rare cases.
Before TLS 1.1
This paragraph is only for the situation before TLS 1.1. Because SSL is a layer below http and does not understand higher-layer protocols, usually SSL servers can only issue certificates to specific IP/port combinations. This means that it often doesn't combine properly with HTTP into HTTPS on virtual hosts (based on domain names).
This has been updated in the upcoming TLS 1.1 - which will fully support domain-based web hosting.
SSL Introduction
SSL (Secure Socket Layer)
was developed by Netscape to ensure the security of data transmission on the Internet. Using data encryption (Encryption) technology, it can ensure that data
will not be intercepted and captured during the transmission process on the network. At present, the general standard is 40-bit security standard, and the United States has introduced a higher security
standard of 128-bit, but it is restricted from leaving the country. As long as IE or Netscape browser version 3.0 or above can support SSL.
The current version is 3.0. It has been widely used for authentication and encrypted data transmission between web browsers and servers.
The SSL protocol is located between the TCP/IP protocol and various application layer protocols, providing security support for data communication. The SSL protocol can be divided into two layers: SSL Record Protocol: It is built on a reliable transmission protocol (such as TCP) and provides support for basic functions such as data encapsulation, compression, and encryption for high-level protocols. SSL Handshake Protocol (SSL Handshake Protocol): It is built on top of the SSL record protocol and is used for authentication, negotiation of encryption algorithms, and exchange of encryption keys before the actual data transmission begins.
The services provided by the SSL protocol mainly include:
1) Authenticate users and servers to ensure that data is sent to the correct client and server;
2) Encrypt data to prevent data from being stolen in the middle;
3) Maintain data integrity and ensure that data is transmitted during transmission is not changed.
The workflow of the SSL protocol:
server authentication phase: 1) The client sends a start message "Hello" to the server to start a new session connection; 2) The server determines whether a new master key needs to be generated according to the client's information, if necessary Then the server will include the information required to generate the master key when responding to the client's "Hello" message; 3) The client generates a master key according to the received server response information, and encrypts it with the server's public key and transmits it to the server ;4) The server recovers the master key and returns a message authenticated with the master key to the client, thereby allowing the client to authenticate the server.
User authentication stage: Before this, the server has passed the client authentication, and this stage mainly completes the authentication of the client. The authenticated server sends a challenge to the client, and the client returns the (digitally) signed challenge and its public key, thereby providing authentication to the server.
From the services provided by the SSL protocol and its workflow, it can be seen that the basis for the operation of the SSL protocol is the merchant's commitment to the confidentiality of consumer information, which is beneficial to the merchant but not to the consumer. In the initial stage of e-commerce, since most of the enterprises operating e-commerce are large companies with high reputation, this problem has not been fully exposed. However, with the development of e-commerce, various small and medium-sized companies have also participated, so the problem of single authentication in the electronic payment process has become more and more prominent. Although the authentication between the browser and the web server can be achieved through digital signature and digital certificate in SSL3.0, there are still some problems in the SSL protocol. In the electronic transaction of , the SSL protocol cannot coordinate the secure transmission and trust relationship between the parties. In this case, Visa and MasterCard, two major credit card companies, have developed the SET protocol, which provides a global standard for online credit card payments.
The handshake process of the SSL protocol In order to better understand and understand the SSL protocol, here we focus on the handshake protocol of the SSL protocol. The SSL protocol uses both public key encryption technology and symmetric encryption technology. Although symmetric encryption technology is faster than public key encryption technology, public key encryption technology provides better authentication technology. The SSL handshake protocol is very effective in allowing the client and the server to complete mutual authentication. The main process is as follows:
① The client's browser transmits the version number of the client's SSL protocol, the type of encryption algorithm, and the generated randomness to the server. data, and other various information required for communication between the server and the client.
②The server sends the version number of the SSL protocol, the type of encryption algorithm, the random number and other related information to the client, and the server will also send its own certificate to the client.
③ The client uses the information sent from the server to verify the legitimacy of the server. The legitimacy of the server includes: whether the certificate has expired, whether the CA that issued the server certificate is reliable, and whether the public key of the issuer certificate can correctly unlock the "issuer's certificate" of the server certificate. Digital Signature", whether the domain name on the server certificate matches the actual domain name of the server. If the legality verification fails, the communication will be disconnected; if the legality verification is passed, the fourth step will be continued.
④ The client randomly generates a "symmetric password" for subsequent communication, and then encrypts it with the server's public key (the server's public key is obtained from the server's certificate in step ②), and then encrypts the encrypted "pre-master". password" to the server.
⑤ If the server requires the client's identity authentication (optional during the handshake process), the user can create a random number and then sign the data, and use the signed random number, the client's own certificate and the encrypted "pre-master". password" to the server.
⑥ If the server requires the client's identity authentication, the server must verify the legitimacy of the client's certificate and the random number of the signature. The specific legality verification process includes: whether the date of use of the client's certificate is valid, whether the CA that provides the client's certificate is reliable, and whether the issuing CA's certificate is valid. Whether the public key can correctly unravel the digital signature of the issuing CA of the client's certificate, check whether the client's certificate is on the Certificate Revocation List (CRL). If the verification fails, the communication is immediately interrupted; if the verification is passed, the server will use its own private key to unlock the encrypted "pre-master password", and then perform a series of steps to generate the master communication password (the client will also generate the master password through the same method) the same master communication password).
⑦The server and the client use the same master password, that is, the "call password", and a symmetric key is used for encryption and decryption of secure data communication of the SSL protocol. At the same time, the integrity of the data communication should be completed during the SSL communication process to prevent any changes in the data communication.
⑧ The client sends a message to the server, indicating that the master password in step ⑦ to be used in the subsequent data communication is a symmetric key, and at the same time informs the server that the client's handshake process is over.
⑨ The server sends a message to the client, indicating that the master password in step ⑦ to be used in the subsequent data communication is a symmetric key, and at the same time informs the client that the server-side handshake process is over.
⑩ The SSL handshake part ends, the data communication of the SSL secure channel begins, the client and the server begin to use the same symmetric key for data communication, and at the same time, the integrity of the communication is checked.
The specific process of the two-way authentication SSL protocol
① The browser sends a connection request to the security server.
② The server sends its own certificate and information related to the certificate to the client browser.
③ The client browser checks whether the certificate sent by the server is issued by a trusted CA center. If it is, continue to execute the protocol; if not, the client browser will give the client a warning message: warn the client that this certificate is not trustworthy, and ask the client if it needs to continue.
④ Then the client browser compares the information in the certificate, such as the domain name and public key, with the relevant message just sent by the server. If they are consistent, the client browser recognizes the legal identity of the server.
⑤ The server asks the client to send the client's own certificate. After receiving it, the server verifies the client's certificate, and if it does not pass the verification, rejects the connection; if it passes the verification, the server obtains the user's public key.
⑥ The client browser tells the server the communication symmetric encryption scheme that it can support.
⑦ The server selects a password scheme with the highest degree of encryption from the password schemes sent by the client, and informs the browser after encrypting it with the client's public key.
⑧ The browser selects a call key for this password scheme, and then encrypts it with the server's public key and sends it to the server.
⑨ The server receives the message sent by the browser, decrypts it with its own private key, and obtains the call key.
⑩ The next communication between the server and the browser uses a symmetric encryption scheme, and the symmetric key is encrypted.
The above is the specific communication process of the two-way authentication SSL protocol, which requires both the server and the user to have certificates. The one-way authentication SSL protocol does not require the client to have a CA certificate. Compared with the above steps, the specific process only needs to remove the process of verifying the client certificate on the server side, and when negotiating a symmetric encryption scheme and a symmetric call key, the server sends a message to the client. is an unencrypted (this does not affect the security of the SSL process) cipher scheme. In this way, the specific communication content between the two parties is the encrypted data. If there is a third-party attack, only the encrypted data is obtained. If the third party wants to obtain useful information, it needs to decrypt the encrypted data. Depends on the security of the cryptographic scheme. Fortunately, the currently used cryptographic schemes are sufficiently secure as long as the length of the communication key is long enough. This is why we emphasize the requirement to use 128-bit encrypted communications.
The meaning of each part of the certificate
<FONT face=宋体>Version The version number of the certificate, the format of different versions of the certificate is different
Serial Number serial number, the certificate serial number issued by the same authentication agency is unique
Algorithm Identifier Signature algorithm, including necessary parameters Issuer authentication agency The identification information
Period of Validity Validity period
Subject identification information of the certificate holder
Subject's Public Key public key of the certificate holder
Signature Signature of the certificate by the authentication authority </FONT>
The format of the certificate The certificates issued by the certification center follow X. 509 V3 standard, its basic format is as follows:
Certificate Format Version
Meaning: used to specify the X.509 version number used in the certificate format.
Certificate Serial Number (Certificate Serial Number)
Meaning: used to specify the unique serial number of the certificate to identify all public key certificates issued by the CA.
Signature Algorithm Identifier
Meaning: used to specify the signature algorithm used by the CA to issue the certificate.
The name of the CA that issued the certificate (Issuer)
Meaning: used to specify the X.500 unique name (DN, Distinguished Name) of the CA that issued the certificate.
Certificate validity period (Validity Period) Start date (notBefore) End date (notAfter)
Meaning: used to specify the start date and end date of the certificate.
User name (Subject)
meaning: used to specify the X.500 unique name (DN, Distinguished Name) of the certificate user.
Subject Public Key Information Algorithm Identifier Algorithm Identifier Subject Public Key
Meaning: used to identify the algorithm used by the public key, including the public key itself.
Certificate Extensions (Extensions)
Meaning: Used to specify additional information.
The extension part (extended domain) and implementation method of X.509 V3 certificate are as follows:
CA's public key identifier (Authority Key Identifier)
Public key identifier (SET is not used) (Key Identifier)
The certificate issuer's distinguished name (Certificate Issuer)
The serial number of the certificate issuer's certificate (Certificate Serial Number)
The extension part (extended domain) of the X.509 V3 certificate and the public key identifier (Authority Key Identifier) of the realization CA
Public key identifier (SET is not used) (Key Identifier)
Distinguished name of the issuer of the certificate issuer's certificate (Certificate Serial Number of the certificate issuer's certificate (Certificate Serial Number)
Meaning: The key pair used by the CA-signed certificate uniquely identifies the user The meaning of Subject Key Identifier
: used to identify the specific key related to the public key in the certificate for decryption. The meaning
of the public key in the certificate (Key Usage)
: used to specify the purpose of the public key.
The user's private key Validity period (Private Key Usage Period) Start date (Note Before) End date (Note After)
Meaning: used to specify the start date and end date of the user's signature private key.
The list of certificate policies recognized by CA (Certificate Policies)
Meaning: use To specify the policy applicable to the user certificate, the certificate policy can be represented by
the object identifier. User Substitutional Name (Substitutional Name)
meaning: used to specify the user's substitute name.
CA's substitute name (Issuer Alt Name)
Meaning: used to specify the CA surrogate name.
Basic Constraints
Meaning: Used to indicate whether the certificate user is an end user or a CA. There are some private extensions (extended fields) in the SET system. Hashed Root Key Meaning: It is only used in the root certificate, and is used for backtracking when the certificate is updated.
Certificate Type (Certificate Type)
meaning: used to distinguish different entities. This item is required.
Merchant Data
Meaning: Contains all the merchant information required by the payment gateway.
Card Cert Required
Meaning: Displays whether the payment gateway supports transactions with cardholders without certificates.
SET Extensions (SETExtensions)
Meaning: SET information extensions that list the payment commands supported by the payment gateway.
CRL data definition version (Version)
Meaning: Display the version number of the CRL.
CRL Issuer (Issuer)
Meaning: Indicates the distinguished name of the CA that issued the CRL.
CRL release time (this Update) Expected next CRL update time (Next Update) Revoked Certificates Directory (Revoked Certificates) CRL Extension (CRL Extension) CA's Public Key Identifier (Authority Key Identifier) CRL Number (CRL Number)
/// ///////////////////////////////////////////// ///////
A few days ago, the customer proposed to force the use of HTTPS to access related projects in Tomcat, so I studied it, and now I write down the specific steps:
主要分2步:让tomcat能使用https--->强制使用https访问
1.让tomcat能使用https
A.在运行命令JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg
RSA -keystore C:\Tomcat\GMAE3.0Tomcat\tomcat.keystore
这样就生成了证书，将证书放到合适的地方（任意地方都可以）
B.打开tomcat目录下的server.xml文件并找到关于ssl的相关段
Java代码
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the JSSE configuration, when using APR, the
connector should be using the OpenSSL style configuration
described in the APR documentation -->
<!--<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />-->
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the JSSE configuration, when using APR, the
connector should be using the OpenSSL style configuration
described in the APR documentation -->
<!--<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />-->
C.去掉注释，添keystoreFile="C:\Tomcat\GMAE3.0Tomcat\tomcat.keystore"
keystorePass="tomcat"的属性
改动完成后配置为:
Java代码
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" keystoreFile="C:\Tomcat\GMAE3.0Tomcat\tomcat.keystore" keystorePass="tomcat" sslProtocol="TLS" />
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" keystoreFile="C:\Tomcat\GMAE3.0Tomcat\tomcat.keystore" keystorePass="tomcat" sslProtocol="TLS" />
D.然后重启tomcat就能使用HTTPS访问
2.强制https访问
在tomcat\conf\web.xml中的</welcome-file-list>后面加上这样一段：
Java代码
<login-config>
<!-- Authorization setting for SSL -->
<auth-method>CLIENT-CERT</auth-method>
<realm-name>Client Cert Users-only Area</realm-name>
</login-config>
<security-constraint>
<!-- Authorization setting for SSL -->
<web-resource-collection >
<web-resource-name >SSL</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<!-- Authorization setting for SSL -->
<auth-method>CLIENT-CERT</auth-method>
<realm-name>Client Cert Users-only Area</realm-name>
</login-config>
<security-constraint>
<!-- Authorization setting for SSL -->
<web-resource-collection >
<web-resource-name >SSL</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
完成以上步骤后，在浏览器中输入http的访问地址也会自动转换为https了