Sie sind auf Seite 1von 8

Certificates of trusted CAs (and their accompanying CRLs) are used in

Zorp to validate the certificates of servers accessed by the clients. The


hashes and structures below are used by the various certificate-related
attributes of the Zorp Pssl proxy, particularly the ones of certificate type.

3.2.3.1. X.509 Certificate Names


A certificate name behaves as a string, and contains a DN in the following
format (also known as one-line format):
/RDN=value/RDN=value/.../RDN=value/

The word RDN stands for relative distinguished name. For example, the
DN cn=Root CA, ou=CA Group, o=Foo Ltd, l=Bar, st=Foobar State, c=US
becomes /C=US/ST=Foobar State/L=Bar/O=Foo Ltd/OU=CA Group/CN=Root
CA/
Warning

The format and representation of certificate names may change in future releases.

3.2.3.2. X.509 Certificate Revocation List


A certifying authority may revoke the issued certificates. A revocation
means that the serial number and the revocation date is added to the list of
revoked certificates. Revocations are published on a regular basis. This list
is called the Certificate Revocation List, also known as CRL. A CRL
always has an issuer, a date when the list was published, and the expected
date of its next update.

3.2.3.3. X.509 Certificate hash


The proxy stores trusted CA certificates in a Certificate hash. This hash can
be indexed by two different types. If an integer index is used, the slot
specified by this value is looked up; if a string index is used, it is
interpreted as a one-line DN value, and the appropriate certificate is looked
up. Each slot in this hash contains an X.509 certificate.

3.2.3.4. X.509 CRL hash


Similarly to the certificate hash, a separate hash for storing Certificate
Revocation Lists was defined. A CRL contains revocation lists associated
to CAs.

3.2.3.5. Certificate verification options


Zorp is able to automatically verify the certificates received. The types of
accepted certificates can be controlled separately on the client and the
server side using the ssl.client_verify_type and the ssl.server_verify_type
attributes. These attributes offer an easy way to restrict encrypted access
only to sites having trustworthy certificates. The available options are
summarized in the following table.

www.balasys.hu 13

Setting the allowed SSL/TLS protocol


Name Value

SSL_VERIFY_NONE Automatic certificate ve

Certificate is optional, if
SSL_VERIFY_OPTIONAL_UNTRUSTED
certificates are accepted

Certificate is optional, b
SSL_VERIFY_OPTIONAL_TRUSTED
certificates signed by a t

Valid certificate is requi


SSL_VERIFY_REQUIRED_UNTRUSTED
certificates are accepted

Certificate is required, o
SSL_VERIFY_REQUIRED_TRUSTED
CA are accepted.
Table 3.2. Certificate verification settings
The ssl.server_check_subject can be used to compare the domain name
provided in the Subject field of the server certificate to application level
information about the server. Currently it can compare the Subject field to
the domain name of the HTTP request in HTTPS communication. If the
ssl.server_check_subject is set to TRUE and ssl.server_verify_type is
SSL_VERIFY_REQUIRED_UNTRUSTED or
SSL_VERIFY_REQUIRED_TRUSTED, the HTTP proxy using the SSL
framework will deny access to the page and return an error if the Subject
field does not match the domain name of the URL.

3.2.4. Setting the allowed SSL/TLS protocol


As there are different and sometimes incompatible releases of the SSL
protocol, it is possible to specify which SSL/TLS version is allowed to pass
the Zorp firewall. The attributes ssl.client_ssl_method and
ssl.server_ssl_method can be used for this purpose. Specify the appropriate
'SSL_METHOD_*' constant to allow the selected protocol. Only one
constant can be specified. Zorp currently supports the SSL versions 2 and 3
and the TLS v1 protocols.

Name Value

SSL_METHOD_SSLV23 Permit the use of SSLv2

SSL_METHOD_SSLV3 Permit the use of SSLv3

SSL_METHOD_TLSV1 Permit the use of TLSv1

SSL_METHOD_TLSV1_1 Permit the use of TLSv1

SSL_METHOD_TLSV1_2 Permit the use of TLSv1

Permit the use of all the


SSL_METHOD_ALL
protocols.
Table 3.3. Constants for SSL/TLS protocol selection
Warning

The OpenSSL implementation of the SSL protocol (used by Zorp) has an important feature regarding
method selection: it allows automatical fallbacks if one side does not support the selected method. That
means that even if SSL_METHOD_SSLv3 is specified, the communication might fall back to SSLv2 if one
of the communicating parties does not support v3. To explicitly deny a protocol, set the appropriate
ssl.client_disable_proto_* or ssl.server_disable_proto_* attribute to TRUE. In Zorp SSLv2 is disabled by
default.

www.balasys.hu

14

SSL cipher selection


3.2.5. SSL cipher selection
The cipher algorithms used for key exchange and mass symmetric
encryption are specified by the attributes ssl.client_ssl_ciphers and
ssl.server_ssl_ciphers. These attributes contain a cipher specification as
specified by the OpenSSL manuals, see the manual page ciphers(ssl) for
further details.

The default set of ciphers can be set by using the following predefined
variables.

Name Value

Permit only the use of ci


SSL_CIPHERS_HIGH
keys.

SSL_CIPHERS_MEDIUM Permit only the use of ci

SSL_CIPHERS_LOW Permit only the use of ci


bits.

Permit the use of all sup


SSL_CIPHERS_ALL
bit exportable ciphers.
Table 3.4. Constants for cipher selection

Cipher specifications as defined above are sorted by key length, the cipher
providing the best key length will be the most preferred.

3.2.6. Enabling STARTTLS


Starting with version 3.3FR1, Zorp supports the STARTTLS method for
encrypting connections. STARTTLS support can be configured separately
for the client- and server side using the ssl.client_connection_security and
ssl.server_connection_security parameters, respectively. The parameters have
the following possible values:
Note

In Zorp 6, the following proxies support STARTTLS: Ftp proxy (to start FTPS sessions), Smtp proxy.

Name Value

SSL_NONE Disable encryption betw

SSL_FORCE_SSL Require encrypted comm

Permit STARTTLS sess


SSL_ACCEPT_STARTTLS
and Smtp proxies.
Table 3.5. Client connection security type.

Name Value
Disable encryption between Zorp and the
SSL_NONE
peer.
www.balasys.hu 15

Keybrigding certificates
Name Value

SSL_FORCE_SSL Require encrypted comm

Forward STARTTLS re
SSL_FORWARD_STARTTLS
only in the Ftp and Smtp
Table 3.6. Server connection security type.

Example 3.1. Configuring FTPS support

This example is a standard FtpProxy with FTPS support enabled.

class FtpsProxy(FtpProxy):
def config(self):
FtpProxy.config(self)
self.max_password_length=64
EncryptionPolicy(name="ForwardSTARTTLS",
encryption=ForwardStartTLSEncryption(client_verify=ClientCertificateVerifier(),
client_ssl_options=ClientSSLOptions(), server_verify=ServerCertificateVerifier(),
server_ssl_options=ServerSSLOptions(),
client_certificate_generator=DynamicCertificate(private_key=PrivateKey.fromFile(key_file_path="/etc/key.d/ZMS_Engi
ne/key.pem"),

trusted_ca=Certificate.fromFile(certificate_file_path="/etc/ca.d/certs/my-trusted-ca-cert.pem",
private_key=PrivateKey.fromFile("/etc/ca.d/keys/my-trusted-ca-cert.pem")),

untrusted_ca=Certificate.fromFile(certificate_file_path="/etc/ca.d/certs/my-untrusted-ca-cert.pem",
private_key=PrivateKey.fromFile("/etc/ca.d/keys/my-untrusted-ca-cert.pem")))))

def demo() :
Service(name='demo/MyFTPSService', router=TransparentRouter(),
chainer=ConnectChainer(), proxy_class=FtpsProxy, max_instances=0, max_sessions=0,
keepalive=Z_KEEPALIVE_NONE, encryption_policy="ForwardSTARTTLS")
Rule(rule_id=2,
proto=6,
service='demo/MyFTPSService'
)
3.2.7. Keybrigding certificates
Keybridging is a method to let the client see a copy of the server's
certificate (or vice versa), allowing it to inspect it and decide about its
trustworthiness. Because of proxying the SSL/TLS connection, the client is
not able to inspect the certificate of the server directly, therefore Zorp
generates a certificate based on the server's certificate on-the-fly. This
generated certificate is presented to the client.

3.2.7.1. Procedure – Configuring keybridging


Purpose:
To configure keybridging in a proxy, complete the following steps.

Steps:
Step 1.

Create the required keys and CAs.


Step a. Generate two local CA certificates. One of them will be used to sign
bridging certificates for servers having trusted certificates, the other one for
servers with untrusted or self-signed certificates. It is useful to reflect this
difference somewhere in the CA's certificates, for example, in their
common name (CA_for_Untrusted_certs;
www.balasys.hu

Das könnte Ihnen auch gefallen