TLS-Design » History » Version 12
Tobias Wich, 10/15/2012 01:46 PM
1 | 5 | Tobias Wich | h1. TLS-Design (iteration from 2012-10-08) |
---|---|---|---|
2 | |||
3 | h2. TLS and related Classes |
||
4 | |||
5 | h3. BouncyCastle Classes |
||
6 | |||
7 | This diagram shows the TLS classes as available in the BouncyCastle library. |
||
8 | 7 | Tobias Wich | |
9 | The "TlsCredentials":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/TlsCredentials.html and "TlsSignerCredentials":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/TlsSignerCredentials.html interface are located in the upper left of the diagram. These interfaces are used in a TLS client authentication to get the client certificate and to produce a signature. For the use of software certificates, BouncyCastle comes with the implementation "DefaultTlsSignerCredentials":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/DefaultTlsSignerCredentials.html. |
||
10 | |||
11 | 9 | Tobias Wich | The common etry point for TLS based communication is the "TlsClient":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/TlsClient.html interface in the lower left. In the current BC version, it has three abstract implementations ("DefaultTlsClient":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/DefaultTlsClient.html "PSKTlsClient":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/PSKTlsClient.html "SRPTlsClient":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/SRPTlsClient.html) which are missing the "getAuthentication()":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/TlsClient.html#getAuthentication() function. |
12 | The class returned by this function has two responsibilities. The fist is the validation of the server certificate and the second is the selection of a client credential depending on the supplied CAs. The CAs can be extracted from the "CertificateRequest":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/CertificateRequest.html (see upper right) parameter in "getClientCredentials()":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/TlsAuthentication.html#getClientCredentials(org.bouncycastle.crypto.tls.CertificateRequest). |
||
13 | |||
14 | The last relevant class in this diagram is the "TlsProtocolHandler":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/TlsProtocolHandler.html. Given a bidirectional stream (usually based on a socket) and a TlsClient, a new bidirectional stream can be extracted which wraps the original stream in a TLS channel. This handler implements the general TLS protocol and triggers the certificate validation and client authentication. |
||
15 | |||
16 | 5 | Tobias Wich | !bc-tls-classes.png! |
17 | |||
18 | h3. Open eCard Classes |
||
19 | |||
20 | This diagram shows classes that make use of the BouncyCastle classes in order to select and use custom credentials for the TLS authentication. |
||
21 | 10 | Tobias Wich | |
22 | 11 | Tobias Wich | The TlsClient interface introduced in [[TLS-Design#BouncyCastle-Classes|BouncyCastle Classes]] is extended with a @setAuthentication()@ function and called @ClientCertTlsClient@. Each client implementing this new interface can be configured at runtime to use a different server certificate validation and to support client authentication. The implementations are derived from the ones in BouncyCastle, so no functions other than @getAuthentication@ and @setAuthentication@ must be implemented. |
23 | 10 | Tobias Wich | |
24 | The @TlsAuthentication@ interface has no implementation in BouncyCastle. With the new capability to compose the @TlsClient@ at runtime, it also makes sense to compose the @TlsAuthentication@ this way. |
||
25 | 11 | Tobias Wich | @TlsNoAuthentication@ implements the certificate verification part, but raises an error, when client authentication is requested. Based on this implementation, the @TlsAuthenticationSelector@ creates the appropriate @TlsSignerCredentials@ for the requested CAs and given restrictions (ConnectionHandle) by the activation (see diagram in [[TLS-Design#Credential-Selection|Credential Selection]]. |
26 | 10 | Tobias Wich | The credential is either selected from a softcert keystore (@SoftKeyStore@) or by inspecting the SALs token. In the latter case, a @SALSignerCredentials@ instance is created and memorized in the selector if further TLS channels must be opened. |
27 | |||
28 | 6 | Tobias Wich | !oec-tls-classes.png! |
29 | 5 | Tobias Wich | |
30 | h3. Apache http-core Classes |
||
31 | |||
32 | 12 | Tobias Wich | This diagram shows classes of and extensions to "Apache http-core":https://hc.apache.org/httpcomponents-core-ga/httpcore/index.html. This library is needed in order to isolate TLS channels from each other. Connection sharing must be explicitly controlled for high securtiy requirements. |
33 | |||
34 | The "TlsProtocolHandler":http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/TlsProtocolHandler.html from BouncyCastle emits streams rather than sockets as usually used in the implementations of "HttpClientConnection":https://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/HttpClientConnection.html. The "AbstractHttpClientConnection":https://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/impl/AbstractHttpClientConnection.html uses "SessionInputBuffer":https://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/io/SessionInputBuffer.html and "SessionOutputBuffer":https://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/io/SessionOutputBuffer.html internally to encapsulate the socket. A stream based implementation is needed as shown by the classes @StreamSessionInputBuffer@ and @StreamSessionOutputBuffer@. |
||
35 | "DefaultConnectionReuseStrategy":https://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/impl/DefaultConnectionReuseStrategy.html is used to determine whether a connection (streams) can be reused after a request-response pair is processed by the HttpClientConnection. |
||
36 | |||
37 | 5 | Tobias Wich | !http-core-classes.png! |
38 | |||
39 | h2. Client creation |
||
40 | |||
41 | The two following diagrams show how the a TLS channel is established and reused. |
||
42 | |||
43 | !tls-client-creation.png! |
||
44 | !tls-client-reuse.png! |
||
45 | |||
46 | h2. Credential Selection |
||
47 | |||
48 | The following two activity charts show the process how a credential is selected for the authentication. |
||
49 | |||
50 | !select-certificate.png! |
||
51 | !select-certificate-from-handles.png! |
||
52 | |||
53 | |||
54 | h1. TLS Design (old version left here until design is finished) |
||
55 | 1 | Tobias Wich | |
56 | 2 | Tobias Wich | h2. Bouncy Castle TLS authentication classes |
57 | 1 | Tobias Wich | !bc-tls.png! |
58 | |||
59 | 2 | Tobias Wich | h2. TLS authentication implementation classes |
60 | 1 | Tobias Wich | !sal-tls.png! |
61 | |||
62 | 2 | Tobias Wich | h2. TLS authentication sequence |
63 | 1 | Tobias Wich | !sal-tls-sequence.png! |
64 | 3 | Simon Potzernheim | |
65 | h1. TLS Design by HSCoburg |
||
66 | |||
67 | h2. Bouncycastle Implementation Design - class diagramm |
||
68 | 4 | Simon Potzernheim | |
69 | Description: TODO |
||
70 | |||
71 | 3 | Simon Potzernheim | !uml_bouncycastleimplementation.png! |