By default, all Derby network traffic
is unencrypted, with the exception of user names and user passwords
which may be encrypted separately (See Network client security). There
is also no network layer access control mechanism. For deployment
scenarios where these are possible security issues, Derby Network Server
supports network security with Secure Socket Layer/Transport Layer
Security (SSL/TLS).
With SSL/TLS, the client/server communication protcol is encrypted
and both the client and the server may independently of each other
require certificate based authentication of the other part.
It is assumed that the reader is somewhat familiar with SSL,
key pairs and certificates. This documentation is also based on the
Sun JDK and its keytool application.
For the remainder of this section, the term SSL is used
for SSL/TLS and the term peer is used for the other part of the
communication (The server's peer is the client and vice versa).
SSL for
Derby
(both for client and for server) operates in three possible modes:
- off
- The default, no SSL encryption
- basic
- SSL encryption, no peer authentication
- peerAuthentication
- SSL encryption and peer authentication
Peer authentication may be set either on the server or on the client
or on both. Peer authentication means that the other side of the SSL
connection is authenticated based on a trusted certificate installed
locally.
Alternatively, a Certification Authority (CA) certificate may be
installed locally and the peer has a certificate signed by that
authority. How to achieve this is not descibed in this
document. Consult your Java environment documentation for details on
this.
Attention:
If a plaintext client tries to communicate with an SSL server or an
SSL client tries to communicate with a plaintext server, the plaintext
side of the communication will see the SSL communication as noise and
report protocol errors.
