The javax.net.ssl.SSLSocket class must be used instead of the java.net.Socket socket class when transferring sensitive data over insecure communication channels. The class SSLSockets provides security protocols such as SSL/TLS to ensure that the channel is not vulnerable to eavesdropping and malicious tampering.
The principal protections included in SSLSockets that are not provided by the Socket class are [[Java API]]:
- Integrity Protection. SSL protects against modification of messages by an active wiretapper.
- Authentication. In most modes, SSL provides peer authentication. Servers are usually authenticated, and clients may be authenticated as requested by servers.
- Confidentiality (Privacy Protection). In most modes, SSL encrypts data being sent between client and server. This protects the confidentiality of data, so that passive wiretappers won't see sensitive data such as financial information or personal information of many kinds.
It is also important to use SSL for secure Remote Method Invocation (RMI) communications because RMI depends on object serialization and serialized data must be safeguarded in transit. Gong et al. [[Gong 2003]] describe how to secure RMI communications using SSLSockets.
Note that this rule makes no assumptions about the integrity of the data being sent down a socket. For information about securiting data integrity, see SER02-J. Sign and seal sensitive objects before sending them outside a trust boundary.
Noncompliant Code Example
This example shows the use of regular sockets for a server application that does not protect sensitive information in transit. The insecure code for the corresponding client application follows the server's code.
// Exception handling has been omitted for the sake of brevity
class EchoServer {
public static void main(String[] args) throws IOException {
ServerSocket serverSocket = null;
try {
serverSocket = new ServerSocket(10007);
Socket socket = serverSocket.accept();
PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream()));
String inputLine;
while ((inputLine = in.readLine()) != null) {
System.out.println(inputLine);
out.println(inputLine);
}
} finally {
try {
serverSocket.close();
} catch (IOException x) {
System.err.println(x.toString());
}
}
}
}
class EchoClient {
public static void main(String[] args) throws UnknownHostException, IOException {
Socket socket = null;
try {
socket = new Socket("localhost", 9999);
PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream()));
BufferedReader stdIn = new BufferedReader(
new InputStreamReader(System.in));
String userInput;
while ((userInput = stdIn.readLine()) != null) {
out.println(userInput);
System.out.println(in.readLine());
}
} finally {
try {
socket.close();
} catch (IOException x) {
System.err.println(x.toString());
}
}
}
}
Note that the sockets are closed in accordance with ERR05-J. Do not let checked exceptions escape from a finally block. While merely printing close exceptions is frowned upon, the exceptions may be suppresed as per EX0 of ERR00-J. Do not suppress or ignore checked exceptions.
Compliant Solution
This compliant solution makes use of SSLSockets to protect packets using the SSL/TLS security protocols.
// Exception handling has been omitted for the sake of brevity
class EchoServer {
public static void main(String[] args) throws IOException {
SSLServerSocket sslServerSocket = null;
try {
SSLServerSocketFactory sslServerSocketFactory =
(SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
sslServerSocket = (SSLServerSocket) sslServerSocketFactory.createServerSocket(9999);
SSLSocket sslSocket = (SSLSocket) sslServerSocket.accept();
PrintWriter out = new PrintWriter( sslSocket.getOutputStream(),true);
BufferedReader in = new BufferedReader(
new InputStreamReader( sslSocket.getInputStream()));
String inputLine;
while ((inputLine = in.readLine()) != null) {
System.out.println(inputLine);
out.println(inputLine);
}
} finally {
try {
sslServerSocket.close();
} catch (IOException x) {
System.err.println(x.toString());
}
}
}
}
class EchoClient {
public static void main(String[] args) throws IOException {
SSLSocket sslSocket = null;
try {
SSLSocketFactory sslSocketFactory =
(SSLSocketFactory) SSLSocketFactory.getDefault();
sslSocket = (SSLSocket) sslSocketFactory.createSocket("localhost", 9999);
PrintWriter out = new PrintWriter(sslSocket.getOutputStream(), true);
BufferedReader in = new BufferedReader(
new InputStreamReader(sslSocket.getInputStream()));
BufferedReader stdIn = new BufferedReader(
new InputStreamReader(System.in));
String userInput;
while ((userInput = stdIn.readLine()) != null) {
out.println(userInput);
System.out.println(in.readLine());
}
} finally {
try {
sslSocket.close();
} catch (IOException x) {
System.err.println(x.toString());
}
}
}
}
Note that a program that makes use of SSLSockets will block indefinitely if it tries to connect to a port that is not using SSL. Similarly, a program that does not use SSLSockets will block when trying to establish a connection through a port that uses SSL.
Exceptions
MSC00-EX0: Because of the mechanisms that SSLSockets provide to ensure the secure transfer of packets, significant performance overhead may result. Regular {Socket}}s are sufficient if:
- The data being sent over the socket is not sensitive
- The data is sensitive, but properly encrypted. See SER02-J. Sign and seal sensitive objects before sending them outside a trust boundary for more information.
- The network path of the socket never crosses a trust boundary. This could happen if, for example, the two endpoings of the socket are within a local network and the entire network is trusted.
Risk Assesment
Using plain sockets instead of SSLSockets means that the data's confidentiality and integrity is not guaranteed.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
MSC00-J |
medium |
likely |
high |
P6 |
L2 |
Automated Detection
The general case of automated detection appears to be infeasible, as determining which specific data may be passed through the socket is not statically computable. An approach that introduces a custom API for passing sensitive data via secure sockets may be feasible. User tagging of sensitive data would be a necessary requirement for such an approach.
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e8dca2c1-d261-477e-a8f1-cc633f30c792"><ac:plain-text-body><![CDATA[ |
[[MITRE 2009 |
AA. Bibliography#MITRE 09]] |
[CWE ID 311 |
http://cwe.mitre.org/data/definitions/311.html] "Failure to Encrypt Sensitive Data" |
]]></ac:plain-text-body></ac:structured-macro> |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="6a10afc8-9cf2-4ad6-99bc-30c352865d64"><ac:plain-text-body><![CDATA[ |
[[API 2006 |
AA. Bibliography#API 06]] |
|
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="83166e81-9f48-4daf-b813-5199de927d93"><ac:plain-text-body><![CDATA[ |
[[Gong 2003 |
AA. Bibliography#Gong 03]] |
11.3.3 "Securing RMI Communications" |
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="561caded-2435-4e78-85c0-ea7f48c0092b"><ac:plain-text-body><![CDATA[ |
[[Ware 2008 |
AA. Bibliography#Ware 08]] |
|
]]></ac:plain-text-body></ac:structured-macro> |