ServicePlatform-v2 finally through HTTPS strong encryption to achieve secure communication, after all, the transmission is the key user account, and we do not have their own VPC.
The lightweight Hessian or Burlup protocols used by RMI of ServicePlatform are based on the HTTP protocol. If deployed properly, user information leakage will not occur without malicious eavesdropping, however, once the platform is enabled and RMI calls are maliciously intercepted, the password verification and user information of the registration service designed in the request will be effective, and the interface of the SP platform will be exposed and user information will be leaked. the complete solution is to force HTTPS to access the RMI interface, while HTTPS is transparent to HTTP (the origin of the so-called nested Layer ), therefore, HTTPS can implement strong encryption for RMI communication without modifying the SP code (configuration descriptor modification cannot be avoided.
By default, ServicePlatform is deployed to force HTTPS access to the RMI interface. In addition to the invoker address configured as HTTPS, the client that uses ServicePlatform also needs to obtain the ServicePlatform certificate. Otherwise, JSSE will not work normally. the following is the deployment descriptor web. mandatory HTTPS access in xml.
<!-- comment below to enable plain HTTP invoker rather than HTTPS only --><security-constraint> <web-resource-collection> <web-resource-name>remote</web-resource-name> <url-pattern>/remote/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint></security-constraint>
The certificate of ServicePlatform is generated by the Java keygen.
% JAVA_HOME % \ bin \ keytool-genkey-alias tomcat-keypass changeit-keyalg RSA-validity 365
Changeit is the key generation password, which must be consistent with the tomcat server deployment descriptor. For more information, see the following server. xml section.
<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystorePass="changeit" keystoreFile="conf/keystore"/>
When generating a certificate, you must enter the correct FQDN of the server that ServicePlatform runs, and then be exactly the same as the fqdn of the invoker URL in the service-dist.properties file,
Otherwise, JSSE regards the certificate as invalid and cannot establish an HTTPS connection. Then, when starting the client, you must add the JVM parameter pointing to the certificate.
-Djavax.net. ssl. trustStore = path \ to \ your \ generated \ keystore \ file
Application Server and JDK version information
Application Server tomcat-5.5.15
JDK 1.5.0 _ 06
How to Implement HTTPS secure connection in Java app Tomcat
SSL or Secure Socket Layer is a technology that allows a web browser to communicate with a web server through a Secure connection. This means that the sent data is translated into a password at one end, sent out, unlocked at the other end, and then processed. This is a two-way process, that is, both the browser and the server need to encrypt the data before sending it.
Another important aspect of the SSL protocol is Authentication ). This means that when you try to communicate with a web server through a secure connection, the server will ask your browser to present a set of certificates, the "authentication" method proves that this is the website you declare.
In some cases, the server will also require your web browser certificate to prove that you are the one you mentioned. This is known as "customer authentication", although in actual situations, it is more used for business-to-business (B2B) transactions than for individual users.
However, most SSL-enabled web servers do not require Client Authentication ).
Certificate
To implement SSL, a web server must have a Certificate (Certificate) for each external interface (IP address) that accepts secure connections ). The theory of this design is that a server must provide a reasonable guarantee to prove that the host of the server is the one you think. This certificate indicates the company associated with the website and some basic contact information of the website owner or system administrator.
This certificate is signed by everyone using a password, and it is very difficult for others to forge it. For websites that conduct e-commerce or any business transaction that is essential to identity authentication, the Certificate should be issued to the well-known Certification Authority (CA )) for example, VeriSign or Thawte. This certificate can be proved by electronic technology. In fact, the certification authority will guarantee the authenticity of the certificate it issued. If you trust the certification authority that issued the certificate, you can believe that the certificate is a copy of the certificate? /Font>
In many cases, authentication is not really worrying. The system administrator may only want to ensure that the data transmitted and received by the server is confidential and will not be stolen by the leader on the connection line. Fortunately, Java provides a relatively simple command line tool called keytool, which can generate a "self-signed" certificate. A self-signed certificate is only a user-generated certificate. It has not been officially registered with the well-known authentication authority. Therefore, it cannot be ensured. But it can ensure the security of data transmission.
Authentication may be important, maybe not. It depends entirely on the needs of the website.
To configure SSL using Tomcat, follow these two steps:
I. Generate a certificate
1. Execute the following command line:
% Java_home % \ bin \ keytool-genkey-alias tomcat-keyalg RSA
In this command, keytool is a tool that comes with JDK to generate certificates. The RSA algorithm is the primary security algorithm, which ensures compatibility with other servers and components.
This command will generate a new file named ". keystore" in your home directory. After the command is executed, you must first display the keystore password. The default password for Tomcat is "changeit" (all in lower case). If you want to use it, you can specify your own password. You also need to specify your password in the server. xml configuration file, which will be described later.
2. You will be asked to provide general information about the certificate, such as the company name and contact name. This information will be displayed to users who attempt to access secure web pages in your program to ensure that the information provided here matches what they expect.
3. You will be asked to display the key password, which is the unique password of the certificate (different from other certificates stored in the same keystore file ). You must use the same password as the keystore password here. (Currently, keytool prompts you to press ENTER to automatically help you do this ).
If everything goes well, you now have a keystore file that can be used by your server.
2. Configure tomcat
The second step is to configure the secure socket in the $ CATALINA_HOME/conf/server. xml file. $ CATALINA_HOME indicates the directory where Tomcat is installed. One example is that the SSL connector element is included in the default server. xml file installed with Tomcat. It looks like this:
$CATALINA_HOME/conf/server.xml< -- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->< !--< Connectorport="8443" minProcessors="5" maxProcessors="75"enableLookups="true" disableUploadTimeout="true"acceptCount="100" debug="0" scheme="https" secure="true";clientAuth="false" sslProtocol="TLS"/>-->
The default form of the Connector element is commented out, so you need to delete the annotation mark around it. Then, you can customize (set by yourself) specific attributes as needed. Generally, you need to add the keystoreFile and keystorePass attributes to specify the path for storing the certificate (for example, keystoreFile = "C :/. keystore ") and the password you just set (for example, keystorePass =" 123456 "). For more information about other options, see Server Configuration Reference.
After completing these configuration changes, you must restart Tomcat, and then you can access any web applications supported by Tomcat through SSL. The command must be as follows: https: // localhost: 8443
Use SSL to Build Secure Sockets
SSL (Secure Sockets Layer) was developed by Netscape in 1994 and was originally used in WEB browsers to provide security for data transmission between browsers and servers, provides encryption, source authentication, and data integrity. SSL3.0 is now widely used, and its transport layer TLS (Transport Layer Security) has become the Internet standard. SSL itself is very similar to TCP socket connections. In the protocol stack, SSL can be simply considered as a secure TCP connection, but it does not support some TCP connection features, for example, out-of-bound ).
When building a Socket-based C/S program, it is a good way to ensure data security and integrity by adding SSL support. The complete Java provides us with a simple implementation method: JSSE (Java Secure Socket Extension ). JSSE is a Java-only SSL and TLS Protocol framework. It abstracts complex SSL and TLS algorithms to simplify security. JSSE has become a standard component in J2SE1.4 and supports SSL 3.0 and TLS 1.0. We will use a specific example to demonstrate some basic applications of JSSE. In this example, the server opens an SSL Socket, and only the client that holds the specified certificate can connect to it. All data transmission is encrypted.
Constructing an SSLSocket is very simple:
SSLServerSocketFactory factory=(SSLServerSocketFactory)SSLServerSocketFactory.getDefault();SSLServerSocket server = (SSLServerSocket) factory.createServerSocket(portNumber);SSLSocket socket = (SSLSocket);
However, executing such a program causes an exception and the report cannot find a trusted certificate. SSLSocket is different from a common Socket. It requires a certificate for security authentication.
I. Certificate
Generate a CA certificate and run the following command on the command line:
Keytool-genkey-keystore SSLKey-keyalg rsa-alias SSL
The simhei part is a parameter that you can specify by yourself. The first parameter is the name of the certificate to be generated, and the second parameter is the certificate alias. Rsa indicates the encryption method we use.
The system will require you to enter the information of the issuer of the certificate, which can be entered one by one, for example:
The file generated by the system will have the same name as the certificate. The certificate can be submitted to an authoritative CA Certification Organization for review. If the certificate is approved, the Organization will provide a trust guarantee to assure the customer that your connection is secure. Of course this is not necessary. In our example, the certificate is directly packaged into the client program to ensure that the client is an authorized user and avoid forging the customer, so it does not need to be submitted for review.
Ii. Server Side
Now you can write the server code. Unlike the common Socket code, we need to import the certificate in the program and use the certificate to construct SSLSocket. It must be noted that:
● KeyStore ks = KeyStore. getInstance ("JKS ");
Access the Java keystore. JKS is the Java keystore created by keytool and stores the keystore.
● KeyManagerFactory kmf = KeyManagerFactory. getInstance ("SunX509 ");
Create an X.509 key manager for managing the JKS keystore.
● SSLContext sslContext = SSLContext. getInstance ("SSLv3 ");
Build an SSL environment, specify the SSL version as 3.0, or use TLSv1, but SSLv3 is more commonly used.
● SslContext. init (kmf. getKeyManagers (), null, null );
Initialize the SSL environment. The second parameter indicates the source of the trusted certificate used by JSSE. If it is set to null, the certificate is obtained from javax.net. ssl. trustStore. The third parameter is the random number generated by JSSE. This parameter affects the security of the system. Setting it to null is a good choice to ensure the security of JSSE.
The complete code is as follows:
/** SSL Socket server side * @ Author Bromon */package org. ec107.ssl; import java.net. *; import javax.net. ssl. *; import java. io. *; import java. security. *; public class SSLServer {static int port = 8266; // The port number to be listened on by the system. 82.6.6 is the birthday of my girlfriend. ^_^ static SSLServerSocket server; /** constructor */public SSLServer () {}/** @ param port listening port number * @ return returns an SSLServerSocket object */private static SSLServerSocket getServerSocket (int thePort) {SSLServerSocket s = null; try {String key = "SSLKey"; // The Certificate Name char keyStorePass [] = "12345678 ". toCharArray (); // certificate password char keyPassword [] = "12345678 ". toCharArray (); // key store ks = KeyStore. getInstance ("JKS"); // create a JKS keystore ks. load (new FileInputStream (key), keyStorePass); // create X.509 key manager KeyManagerFactory kmf = KeyManagerFactory that manages the JKS keystore. getInstance ("SunX509"); kmf. init (ks, keyPassword); SSLContext sslContext = SSLContext. getInstance ("SSLv3"); sslContext. init (kmf. getKeyManagers (), null, null); // generate SSLServerSocketFactory Based on the SSL context configured above, which is different from the common generation method SSLServerSocketFactory = sslContext. getServerSocketFactory (); s = (SSLServerSocket) factory. createServerSocket (thePort);} catch (Exception e) {System. out. println (e);} return (s);} public static void main (String args []) {try {server = getServerSocket (port); System. out. println ("in" + port + "port waiting for connection... "); while (true) {SSLSocket socket = (SSLSocket) server. accept (); // send the obtained socket to the CreateThread object for processing. The main thread continues to listen to new CreateThread (socket) ;}} catch (Exception e) {System. out. println ("main method error 80:" + e) ;}}/ ** internal class to obtain the socket connection of the main thread, generate a sub-Thread to process */class CreateThread extends Thread {static BufferedReader in; static PrintWriter out; static Socket s;/** constructor to obtain socket connections, initialize the in and out objects */public CreateThread (Socket socket) {try {s = socket; in = new BufferedReader (new InputStreamReader (s. getInputStream (), "gb2312"); out = new PrintWriter (s. getOutputStream (), true); start (); // run the run method on a new thread} catch (Exception e) {System. out. println (e) ;}}/** thread method to process data transmitted by socket */public void run () {try {String msg = in. readLine (); System. out. println (msg); s. close ();} catch (Exception e) {System. out. println (e );}}}
Put the certificate we just generated in the directory where the program is located. The above code can be compiled and executed:
Java org. ec107.ssl. SSLServer
Wait for connection on port 8266...
Iii. Client
The client code is relatively simple. Instead of specifying the SSL environment in the program, we can specify the environment when executing the client program. Note that the client does not import the certificate, but uses the default factory method to construct SSLSocket:
● SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory. getDefault ();
Construct the default factory Method
● Socket s = factory. createSocket ("localhost", port );
Open an SSLSocket connection
/** SSL Socket Client * @ Author Bromon */package org. ec107.ssl; import java.net. *; import javax.net. ssl. *; import javax.net. *; import java. io. *; public class SSLClient {static int port = 8266; public static void main (String args []) {try {SSLSocketFactory = (SSLSocketFactory) SSLSocketFactory. getDefault (); Socket s = factory. createSocket ("localhost", port); PrintWriter out = new PrintWriter (s. getOutputStream (), true); out. println ("Safe say hello"); out. close (); s. close ();} catch (Exception e) {System. out. println (e );}}}
Copy the certificate (SSLKey) generated by the server to the directory where the program is located. When executing this program, you need to input the certificate name to the javax.net. ssl. trustStore environment variable:
Java -Djavax.net. ssl. trustStore = SSLKey org. ec107.ssl. SSLClient
That is:
Public static void main (String args []) {try {System. setProperty ("javax.net. ssl. trustStore ", (new PathTest ()). getClass (). getResource ("/SSLKey "). getFile (); SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory. getDefault (); Socket s = factory. createSocket ("localhost", port); PrintWriter out = new PrintWriter (s. getOutputStream (), true); out. println ("Safe say hello"); out. close (); s. close ();} catch (Exception e) {System. out. println (e );}}
You can view the data sent from the client on the server console.
The execution client can have another method: copy the certificate to the java home/lib/security directory, change the name to jssecacerts, and then directly execute the client:
Java org. ec107.ssl. SSLClient
The program will automatically go to the above directory to find the jssecacerts file as the default certificate. Note that the java home here is not the JAVA_HOME we specified when installing J2SE. You can execute a program to get the location of java home:
public class GetJavaHome{ public static void main(String args[]) { System.out.println(System.getProperty(“java.home”)); }}
Generally (windows 2 K) hava home is located in C: Program FilesJavaj2re1.4.0 _ 02, and the certificate should be copied to C: Program FilesJavaj2re1.4.0 _ 02libsecurity, if Java IDE with built-in JDK is installed, such as JBuilder, the situation may be different.
If the client directly connects without a certificate, the server will encounter an exception during running and the connection is not allowed.
Running Environment: Windows 2 k server, j2sdk1.4.1