SSL-Profilinfrastruktur

Sicherheitsanfälligkeiten in der SSLv3- und RC4-Implementierung haben betont, dass die neuesten Verschlüsselungen und Protokolle verwendet werden müssen, um die Sicherheitseinstellungen für eine Netzwerkverbindung auszuhandeln. Das Implementieren von Änderungen an der Konfiguration, wie das Deaktivieren von SSLv3 über Tausende von SSL-Endpunkten, ist ein umständlicher Prozess. Daher wurden Einstellungen, die Teil der SSL-Endpunktkonfiguration waren, zusammen mit den Standardverschlüsselungen in die SSL-Profile verschoben. Um Änderungen in der Konfiguration zu implementieren, einschließlich der Verschlüsselungsunterstützung, müssen Sie nur das Profil ändern, das an die Entitäten gebunden ist.

Die Standard-Front-End- und Standard-Back-End-SSL-Profile enthalten zusätzlich zu den Einstellungen, die Teil der alten Profile waren, alle Standardchiffrier- und ECC-Kurven. Beispielausgaben für die Standardprofile sind im Anhang enthalten. Der Vorgang Standardprofil aktivieren bindet das Standard-Front-End-Profil automatisch an alle Front-End-Entitäten und das Standard-Back-End-Profil an alle Back-End-Entitäten. Sie können ein Standardprofil entsprechend Ihrer Bereitstellung ändern. Sie können auch benutzerdefinierte Profile erstellen und an SSL-Entitäten binden.

Das Front-End-Profil enthält Parameter, die für eine Front-End-Entität gelten. Das heißt, sie gelten für die Entität, die Anforderungen von einem Client empfängt. In der Regel handelt es sich bei dieser Entität um einen virtuellen SSL-Server oder einen transparenten SSL-Dienst auf der Citrix ADC Appliance. Das Back-End-Profil enthält Parameter, die für eine Backend-Entität gelten. Das heißt, sie gelten für die Entität auf der ADC-Appliance, die Client-Anfragen an einen Back-End-Server sendet. In der Regel ist diese Entität ein SSL-Dienst auf der Citrix ADC Appliance. Wenn Sie versuchen, einen nicht unterstützten Parameter zu konfigurieren, wird der Fehler ERROR: Specified parameters are not applicable for this type of SSL profile angezeigt.

Wichtig:

• Ein SSL-Profil hat Vorrang vor SSL-Parametern. Das heißt, wenn Sie SSL-Parameter mit dem set ssl parameter Befehl konfigurieren und später ein Profil an eine SSL-Entität binden, haben die Einstellungen im Profil Vorrang.

• Wenn Sie nach dem Upgrade die Standardprofile aktivieren, können Sie die Änderungen nicht rückgängig machen. Das heißt, die Profile können nicht deaktiviert werden. Speichern Sie die Konfiguration und erstellen Sie eine Kopie der Konfigurationsdatei (ns.conf), bevor Sie die Profile aktivieren. Wenn Sie jedoch die Features im Standardprofil nicht verwenden möchten, können Sie weiterhin die alten SSL-Profile verwenden. Weitere Informationen zu diesen Profilen finden Sie unter Legacy-SSL-Profil.

• Ab Release 11.1 51.x wird in der GUI und CLI eine Bestätigungsaufforderung hinzugefügt, wenn Sie das Standardprofil aktivieren, um zu verhindern, dass es versehentlich aktiviert wird.

Befehl:

set ssl parameter -defaultProfile ENABLED
    Save your configuration before enabling the Default profile. You cannot undo the changes. Are you sure you want to enable the Default profile? [Y/N]Y
Done
<!--NeedCopy-->

Standardmäßig gelten einige SSL-Parameter, sogenannte globale Parameter, für alle SSL-Endpunkte. Wenn ein Profil jedoch an einen SSL-Endpunkt gebunden ist, gelten die globalen Parameter nicht. Stattdessen gelten die im Profil angegebenen Einstellungen.

Punkte zu beachten

1. Ein Profil kann an mehrere virtuelle Server gebunden werden, aber ein virtueller Server kann nur über ein Profil gebunden sein.
2. Um ein Profil zu löschen, das an einen virtuellen Server gebunden ist, heben Sie zunächst die Bindung des Profils auf.
3. Eine Chiffre- oder Chiffriergruppe kann an mehrere Profile mit unterschiedlichen Prioritäten gebunden werden.
4. Ein Profil kann mehrere Chiffre und Verschlüsselungsgruppen an unterschiedliche Prioritäten gebunden sein.
5. Änderungen an einer Chiffregruppe werden sofort in allen Profilen und in allen virtuellen Servern widergespiegelt, an die eines der Profile gebunden ist.
6. Wenn eine Verschlüsselungssuite Teil einer Verschlüsselungsgruppe ist, bearbeiten Sie die Verschlüsselungsgruppe, um diese Verschlüsselungssuite zu entfernen, bevor Sie die Verschlüsselungssuite aus dem Profil entfernen.
7. Wenn Sie einer mit einem Profil verknüpften Verschlüsselungsgruppe oder einer Chiffriergruppe keine Priorität zuweisen, wird ihr die niedrigste Priorität innerhalb des Profils zugewiesen.
8. Sie können eine benutzerdefinierte Verschlüsselungsgruppe (auch als benutzerdefinierte Verschlüsselungsgruppe bezeichnet) aus vorhandenen Verschlüsselungsgruppen und Verschlüsselungssammlungen erstellen. Wenn Sie Chiffriergruppe A erstellen und vorhandene Chiffriergruppen X und Y hinzufügen, wird Y in dieser Reihenfolge mit einer niedrigeren Priorität als X zugewiesen. Das heißt, die zuerst hinzugefügte Gruppe hat eine höhere Priorität.
9. Wenn eine Cipher Suite Teil von zwei Verschlüsselungsgruppen ist, die an dasselbe Profil angehängt sind, wird die Cipher-Suite nicht als Teil der zweiten Verschlüsselungsgruppe hinzugefügt. Die Chiffre Suite mit der höheren Priorität ist wirksam, wenn Datenverkehr verarbeitet wird.
10. Verschlüsselungsgruppen werden im Profil nicht erweitert. Dadurch wird die Anzahl der Zeilen in der Konfigurationsdatei (ns.conf) stark reduziert. Wenn beispielsweise zwei Verschlüsselungsgruppen mit jeweils 15 Verschlüsselungen an tausend virtuelle SSL-Server gebunden sind, fügt die Erweiterung 30* 1000 verschlüsselungsbezogene Einträge in der Konfigurationsdatei hinzu. Mit dem neuen Profil hätte es nur zwei Einträge: einen für jede Verschlüsselungsgruppe, die an ein Profil gebunden ist.
11. Das Erstellen einer benutzerdefinierten Verschlüsselungsgruppe aus vorhandenen Verschlüsselungsgruppen und Chiffriergruppen ist eine Kopier- und Einfügeoperation. Änderungen in der ursprünglichen Gruppe werden nicht in der neuen Gruppe wiedergegeben.
12. Eine benutzerdefinierte Verschlüsselungsgruppe listet alle Profile auf, zu denen sie gehört.
13. Ein Profil listet alle virtuellen SSL-Server, -Dienste und -Dienstgruppen auf, an die es gebunden ist.
14. Wenn die standardmäßige SSL-Profilfunktion aktiviert ist, verwenden Sie das Profil, um eines der Attribute einer SSL-Entität festzulegen oder zu ändern. Zum Beispiel virtueller Server, Dienst, Dienstgruppe oder ein interner Dienst.

Speichern der Konfiguration mit der CLI

Geben Sie an der Eingabeaufforderung Folgendes ein:

save config

shell

root@ns# cd /nsconfig

root@ns# cp ns.conf ns.conf.NS<currentreleasenumber><currentbuildnumber>
<!--NeedCopy-->

Beispiel:

save config
shell
root@ns# cd /nsconfig
root@ns# cp ns.conf ns.conf.NS.11.0.jun.16
<!--NeedCopy-->

Aktivieren des Standardprofils

Wichtig:

Speichern Sie Ihre Konfiguration, bevor Sie die Software aktualisieren, und aktivieren Sie die Standardprofile.

Ab Release 11.1 Build 51.x erscheint in der GUI und CLI eine Bestätigungsaufforderung, wenn Sie das Standardprofil aktivieren, um zu vermeiden, dass es versehentlich aktiviert wird.

Befehl: Der folgende Befehl aktiviert das Standardprofil und bindet dieses Profil an die SSL-Entitäten, an die ein Profil bereits gebunden ist. Das heißt, wenn ein Profil (zum Beispiel P1) bereits an eine SSL-Entität gebunden ist, ersetzt das Standard-Front-End-Profil oder das Standard-Back-End-Profil P1. Das ältere Profil (P1) wird nicht gelöscht. Es ist jetzt ein erweitertes SSL-Profil und enthält die früheren Einstellungen sowie die Chiffre und ECC-Kurven. Wenn Sie das Standardprofil nicht möchten, können Sie P1 explizit an die SSL-Entität binden.

set ssl parameter -defaultProfile ENABLED
    Save your configuration before enabling the Default profile. You cannot undo the changes. Are you sure you want to enable the Default profile? [Y/N]Y
Done
<!--NeedCopy-->

Aktualisieren Sie die Software auf einen Build, der die erweiterte Profilinfrastruktur unterstützt, und aktivieren Sie dann die Standardprofile.

Hinweise:

• Wenn ein Legacy-Profil (P1) bereits an eine SSL-Entität gebunden ist und Sie das Standardprofil aktivieren, überschreibt das Standardprofil die frühere Bindung. Das heißt, das Standardprofil ist an die SSL-Entitäten gebunden. Wenn das Standardprofil nicht gebunden werden soll, müssen Sie P1 erneut an die SSL-Entität binden.

• Ein einzelner Vorgang (Standardprofil aktivieren oderset ssl parameter -defaultProfile ENABLED) aktiviert (bindet) sowohl das Standard-Front-End-Profil als auch das Standard-Back-End-Profil.

Anwendungsfall

Nachdem Sie die Standardprofile aktiviert haben, sind sie an alle SSL-Endpunkte gebunden. Die Standardprofile können bearbeitet werden. Wenn Ihre Bereitstellung die meisten Standardeinstellungen verwendet und nur wenige Parameter ändert, können Sie die Standardprofile bearbeiten. Die Änderungen werden sofort über alle Endpunkte reflektiert. Sie können auch benutzerdefinierte SSL-Profile mit einigen benutzerdefinierten und einigen Standardparametern erstellen und an die SSL-Entitäten binden.

Im folgenden Flussdiagramm werden die Schritte erläutert, die Sie ausführen müssen:

1. Informationen zum Upgrade der Software finden Sie unter Upgrade der Systemsoftware.

2. Aktivieren Sie die Standardprofile mit der CLI oder GUI.

• Geben Sie in der Befehlszeile Folgendes ein: set ssl parameter -defaultProfile ENABLED
• Wenn Sie die GUI bevorzugen, navigieren Sie zu Traffic Management > SSL > Erweiterte SSL-Einstellungen ändern, scrollen Sie nach unten, und wählen Sie Standardprofil aktivieren aus.

Wenn ein Profil vor dem Upgrade nicht an einen Endpunkt gebunden war, ist ein Standardprofil an den SSL-Endpunkt gebunden. Wenn ein Profil vor dem Upgrade an einen Endpunkt gebunden wurde, wird dasselbe Profil nach dem Upgrade gebunden, und Standardchiffre werden dem Profil hinzugefügt.

1. (Optional) Ändern Sie manuell alle Einstellungen im Standardprofil.

• Geben Sie in der Befehlszeile:set ssl profile <name> gefolgt von den zu ändernden Parametern ein.
• Wenn Sie die GUI lieber verwenden möchten, navigieren Sie zu System > Profile. Wählen Sie in SSL Profilesein Profil aus und klicken Sie auf Edit.

SSL-Profilparameter

Sie können die folgenden SSL-Parameter in einem SSL-Profil festlegen. Sie können einige dieser Parameter in einem virtuellen SSL-Server festlegen. Weitere Informationen zu Parametern für virtuelle SSL-Server finden Sie unter Parameter für virtuelle SSL-Server.

Unterstützung für sichere Neuverhandlungen am Backend einer Citrix ADC Appliance

Hinweis: Dieser Parameter wird in Version 13.0 Build 58.x und höher eingeführt. In früheren Releases und Builds wurde im Back-End nur unsichere Neuverhandlungen unterstützt.

Die Funktion wird auf den folgenden Plattformen unterstützt:

• VPX
• MPX-Plattformen, die N2- oder N3-Chips enthalten
• Plattformen mit Intel Coleto SSL Chips

Die Funktion wird auf der FIPS-Plattform noch nicht unterstützt.

Eine sichere Neuverhandlung wird standardmäßig am Back-End einer ADC-Appliance verweigert. Das heißt, der denySSLReneg Parameter ist auf ALL (Standard) festgelegt.

Um eine sichere Neuverhandlung auf dem Back-End zu ermöglichen, wählen Sie eine der folgenden Einstellungen für den Parameter denySSLReneg aus:

• NEIN
• FRONTEND_CLIENT
• FRONTEND_CLIENTSERVER
• NONSECURE

Sichere Neuverhandlung über die CLI aktivieren

Geben Sie an der Eingabeaufforderung Folgendes ein:

set ssl profile <name> -denySSLReneg <denySSLReneg>

Beispiel:

set ssl profile ns_default_ssl_profile_backend -denySSLReneg NONSECURE
 Done

sh ssl profile ns_default_ssl_profile_backend
1)  Name: ns_default_ssl_profile_backend    (Back-End)
    SSLv3: DISABLED TLSv1.0: ENABLED  TLSv1.1: ENABLED  TLSv1.2: ENABLED  TLSv1.3: DISABLED
    Server Auth: DISABLED
    Use only bound CA certificates: DISABLED
    Strict CA checks:       NO
    Session Reuse: ENABLED      Timeout: 300 seconds
    DH: DISABLED
    Ephemeral RSA: DISABLED
    Deny SSL Renegotiation      NONSECURE
    Non FIPS Ciphers: DISABLED
    Cipher Redirect: DISABLED
    SSL Redirect: DISABLED
    Send Close-Notify: YES
    Strict Sig-Digest Check: DISABLED
    Push Encryption Trigger: Always
    PUSH encryption trigger timeout:    1 ms
    SNI: DISABLED
    OCSP Stapling: DISABLED
    Strict Host Header check for SNI enabled SSL sessions:      NO
    Push flag:  0x0 (Auto)
    SSL quantum size:       8 kB
    Encryption trigger timeout  100 mS
    Encryption trigger packet count:    45

    ECC Curve: P_256, P_384, P_224, P_521

1)  Cipher Name: DEFAULT_BACKEND        Priority :2
    Description: Predefined Cipher Alias

1)  Service Name: s187
 Done
<!--NeedCopy-->

Ermöglichen Sie sichere Neuverhandlungen mit der GUI

1. Navigieren Sie zu System > Profile > SSL-Profil.
2. Fügen Sie ein Profil hinzu oder bearbeiten Sie es.

3. Setzen Sie Deny SSL Renegotiation auf einen anderen Wert als ALL.

Validierung von Host-Head

Hinweis: Dieser Parameter wird in Version 13.0 build 52.x eingeführt.

Mit HTTP/1.1 mussten Clients mehrere Verbindungen verwenden, um mehrere Anfragen zu verarbeiten. Mit HTTP/2 können Clients Verbindungen zwischen Domänen wiederverwenden, die von demselben Zertifikat abgedeckt sind. Für eine SNI-aktivierte Sitzung muss die ADC-Appliance in der Lage sein zu steuern, wie der HTTP-Host-Header validiert wird, um dieser Änderung Rechnung zu tragen. In früheren Builds wurde die Anforderung gelöscht, wenn der Parameter aktiviert war (auf “Ja” gesetzt) und die Anfrage nicht den Host-Header für eine SNI-aktivierte Sitzung enthielt. Wenn der Parameter deaktiviert wurde (auf “Nein” gesetzt), hat die Appliance die Validierung nicht durchgeführt. Ein neuer Parameter SNIHTTPHostMatch wird zu einem SSL-Profil und globalen SSL-Parametern hinzugefügt, um diese Validierung besser kontrollieren zu können. Dieser Parameter kann drei Werte annehmen: CERT, STRICT und NONE. Diese Werte funktionieren nur für SNI-aktivierte Sitzungen wie folgt. SNI muss auf dem virtuellen SSL-Server oder dem an den virtuellen Server gebundenen Profil aktiviert sein, und die HTTP-Anfrage muss den Host-Header enthalten.

• CERT - Die Verbindung wird weitergeleitet, wenn der Host-Header-Wert in der Anfrage durch das Zertifikat abgedeckt wird, mit dem diese SSL-Sitzung eingerichtet wurde.
• STRICT - Die Verbindung wird nur weitergeleitet, wenn der Host-Header-Wert in der Anfrage mit dem Servernamenwert übereinstimmt, der in der Client Hello Nachricht der SSL-Verbindung übergeben wurde.
• NO - Der Host-Headerwert wird nicht validiert.

Mögliche Werte: NO, CERT, STRICT Standardwert: CERT

Mit der Einführung des neuen Parameters SNIHTTPHostMatch ändert sich das Verhalten des Parameters dropReqWithNoHostHeader. Die Einstellung des Parameters dropReqWithNoHostHeader wirkt sich nicht mehr darauf aus, wie der Host-Header mit dem SNI-Zertifikat validiert wird.

Festlegen von SSL-Profilparametern mit der CLI

Geben Sie an der Eingabeaufforderung Folgendes ein:

set ssl profile <name> [-ssllogProfile <string>] [-dh ( ENABLED | DISABLED ) -dhFile <string>] [-dhCount <positive_integer>][-dhKeyExpSizeLimit ( ENABLED | DISABLED )] [-eRSA ( ENABLED | DISABLED) [-eRSACount <positive_integer>]] [-sessReuse ( ENABLED | DISABLED )
[-sessTimeout <positive_integer>]] [-cipherRedirect ( ENABLED | DISABLED ) [-cipherURL <URL>]] [-clientAuth ( ENABLED | DISABLED )[-clientCert ( Mandatory | Optional )]] [-sslRedirect ( ENABLED |
DISABLED )] [-redirectPortRewrite ( ENABLED | DISABLED )] [-ssl3 (ENABLED | DISABLED )] [-tls1 ( ENABLED | DISABLED )] [-tls11 ( ENABLED| DISABLED )] [-tls12 ( ENABLED | DISABLED )] [-tls13 ( ENABLED |DISABLED )] [-SNIEnable ( ENABLED | DISABLED )] [-ocspStapling (ENABLED | DISABLED )] [-serverAuth ( ENABLED | DISABLED )] [-commonName <string>] [-pushEncTrigger <pushEncTrigger>] [-sendCloseNotify ( YES |
NO )] [-clearTextPort <port|*>] [-insertionEncoding ( Unicode | UTF-8)] [-denySSLReneg <denySSLReneg>] [-quantumSize <quantumSize>]
[-strictCAChecks ( YES | NO )] [-encryptTriggerPktCount <positive_integer>] [-pushFlag <positive_integer>][-dropReqWithNoHostHeader ( YES | NO )] [-SNIHTTPHostMatch <SNIHTTPHostMatch>] [-pushEncTriggerTimeout <positive_integer>]
[-sslTriggerTimeout <positive_integer>] [-clientAuthUseBoundCAChain (ENABLED | DISABLED )] [-sslInterception ( ENABLED | DISABLED )][-ssliReneg ( ENABLED | DISABLED )] [-ssliOCSPCheck ( ENABLED | DISABLED )] [-ssliMaxSessPerServer <positive_integer>] [-HSTS ( ENABLED| DISABLED )] [-maxage <positive_integer>] [-IncludeSubdomains ( YES | NO )] [-preload ( YES | NO )] [-sessionTicket ( ENABLED | DISABLED )][-sessionTicketLifeTime <positive_integer>] [-sessionTicketKeyRefresh (ENABLED | DISABLED )] {-sessionTicketKeyData } [-sessionKeyLifeTime <positive_integer>] [-prevSessionKeyLifeTime <positive_integer>]
[-cipherName <string> -cipherPriority <positive_integer>][-strictSigDigestCheck ( ENABLED | DISABLED )]
[-skipClientCertPolicyCheck ( ENABLED | DISABLED )] [-zeroRttEarlyData ( ENABLED | DISABLED )] [-tls13SessionTicketsPerAuthContext
<positive_integer>] [-dheKeyExchangeWithPsk ( YES | NO )]
<!--NeedCopy-->

Festlegen von SSL-Profilparametern mit der GUI

So fügen Sie ein Profil hinzu:

1. Navigieren Sie zu System > Profile.
2. Wählen Sie SSL-Profile aus. Klicken Sie auf Hinzufügen.
3. Geben Sie Werte für die verschiedenen Parameter an.
4. Klicken Sie auf OK.
5. Klicken Sie auf Fertig.

So verwenden Sie ein vorhandenes SSL-Profil wieder:

1. Navigieren Sie zu System > Profile.
2. Wählen Sie ein vorhandenes Profil aus und klicken Sie auf Hinzufügen.
3. Geben Sie einen anderen Namen an, ändern Sie alle Parameter und klicken Sie auf OK.
4. Klicken Sie auf Fertig.

TLS-Sitzungsticketerweiterung

Ein SSL-Handshake ist ein CPU-intensiver Betrieb. Wenn die Sitzungswiederverwendung aktiviert ist, wird der Server-/Clientschlüsselaustauschvorgang für vorhandene Clients übersprungen. Sie dürfen ihre Sitzungen fortsetzen. Diese Aktion verbessert die Antwortzeit und erhöht die Anzahl der SSL-Transaktionen pro Sekunde, die ein Server unterstützen kann. Allerdings muss der Server Details zu jedem Sitzungsstatus speichern, der Speicher belegt und schwer auf mehreren Servern freigegeben werden kann, wenn Anforderungen über Server verteilt werden.

Citrix ADC Appliances unterstützen die SessionTicket TLS-Erweiterung. Die Verwendung dieser Erweiterung zeigt an, dass die Sitzungsdetails auf dem Client und nicht auf dem Server gespeichert werden. Der Client muss angeben, dass er diesen Mechanismus unterstützt, indem er die TLS-Erweiterung des Sitzungstickets in die Client-Hello -Nachricht einschließt. Für neue Clients ist diese Erweiterung leer. Der Server sendet ein neues Sitzungsticket in der NewsessionTicket-Handshake-Nachricht. Das Sitzungsticket wird verschlüsselt, indem ein Schlüsselpaar verwendet wird, das nur dem Server bekannt ist. Wenn ein Server jetzt kein neues Ticket ausstellen kann, wird ein normaler Handshake abgeschlossen.

Diese Funktion ist nur in Front-End-SSL-Profilen und nur am Frontend der Kommunikation verfügbar, bei der die Appliance als Server fungiert und Sitzungstickets generiert.

Einschränkungen

• Diese Funktion wird auf einer FIPS-Plattform nicht unterstützt.
• Diese Funktion wird nur mit TLS-Versionen 1.1 und 1.2 unterstützt.
• Die Persistenz der SSL-Sitzungs-ID wird bei Sitzungstickets nicht unterstützt.

Aktivieren der TLS-Sitzungsticketerweiterung mit der CLI

Geben Sie an der Eingabeaufforderung Folgendes ein:

set ssl profile <name> -sessionTicket (ENABLED | DISABLED ) [-sessionTicketLifeTime <positive_integer>
<!--NeedCopy-->

Argumente:

SessionTicket: Status der TLS-Sitzungsticketerweiterung. Die Verwendung dieser Erweiterung zeigt an, dass die Sitzungsdetails auf dem Client und nicht auf dem Server gespeichert werden, wie in RFC 5077 definiert.

Mögliche Werte: ENABLED, DISABLED

Standardwert: DISABLED

SessionTicketLifetime: Geben Sie eine Zeit in Sekunden an, nach der das Sitzungsticket abläuft und ein neuer SSL-Handshake gestartet werden muss.

Standardwert: 300

Mindestwert: 0

Maximalwert: 172800

Beispiel:

add ssl profile profile1 -sessionTicket ENABLED -sessionTicketlifeTime 300
Done
<!--NeedCopy-->

Aktivieren der TLS-Sitzungsticketerweiterung mit der GUI

1. Navigieren Sie zu System > Profile. Wählen Sie SSL-Profile aus.
2. Klicken Sie auf Hinzufügen, und geben Sie einen Namen für das Profil an.
3. Wählen Sie Sitzungsticketaus.
4. Geben Sie optional die Gültigkeitsdauer des Sitzungstickets (Sekunden)an.

Sichere Implementierung von Sitzungstickets

Mithilfe von TLS-Sitzungstickets können Clients abgekürzte Handshakes für eine schnellere Wiederherstellung der Verbindung zu Servern verwenden. Wenn Sitzungstickets jedoch nicht verschlüsselt oder über längere Zeit geändert werden, können sie ein Sicherheitsrisiko darstellen. Sie können Sitzungstickets sichern, indem Sie sie mit einem symmetrischen Schlüssel verschlüsseln. Um die Weiterleitungsgeheimnis zu erreichen, können Sie ein Zeitintervall angeben, in dem der Sitzungsticketschlüssel aktualisiert wird.

Die Appliance generiert standardmäßig die Sitzungsticket-Schlüssel. Wenn jedoch mehrere Appliances in einer Bereitstellung die Sitzungstickets des anderen entschlüsseln müssen, müssen sie alle denselben Sitzungsticketschlüssel verwenden. Daher müssen Sie die gleichen Sitzungs-Ticket-Schlüsseldaten manuell auf allen Appliances festlegen (hinzufügen oder laden). Die Schlüsseldaten für das Session-Ticket umfassen folgende Informationen:

• Name des Sitzungstickets.
• Sitzungs-AES-Schlüssel, der zum Verschlüsseln oder Entschlüsseln des Tickets verwendet wird.
• Session-HMAC-Schlüssel verwendet, um den Digest des Tickets zu berechnen.

Sie können jetzt Sitzungsticketschlüsseldaten der Länge 64 Byte so konfigurieren, dass 256-Bit-HMAC-Schlüssel unterstützt werden, wie in RFC 5077 empfohlen. Aus Gründen der Abwärtskompatibilität werden auch Schlüssellängen von 48 Byte unterstützt.

Hinweis:

Stellen Sie beim manuellen Eingeben der Sitzungsticketschlüsseldaten sicher, dass die Konfiguration über alle Citrix ADC Appliances in einem HA-Setup oder in einem Cluster-Setup identisch ist.

DersessionTicketKeyLifeTime Parameter gibt an, wie oft ein Sitzungsticketschlüssel aktualisiert wird. Sie können denprevSessionTicketKeyLifeTime Parameter festlegen, um festzulegen, wie lange der vorherige Sitzungsticketschlüssel für die Entschlüsselung von Tickets mit diesem Schlüssel beibehalten wird, nachdem ein neuer Schlüssel generiert wurde. DieprevSessionTicketKeyLifeTime Einstellung verlängert die Zeit, für die ein Client einen abgekürzten Handshake verwenden kann, um die Verbindung wiederherzustellen. Wenn beispielsweise auf 10 Minuten undsessionTicketKeyLifeTime auf 5 Minuten festgelegtprevSessionTicketKeyLifeTime ist, wird nach 10 Minuten ein neuer Schlüssel generiert und für alle neuen Sitzungen verwendet. Allerdings haben zuvor verbundene Kunden weitere 5 Minuten, für die zuvor ausgestellte Tickets für einen abgekürzten Handshake geehrt werden.

Konfigurieren von SSL-Session-Ticket-Daten mit der CLI

Geben Sie an der Eingabeaufforderung Folgendes ein:

set ssl profile <name> -sessionTicket ENABLED -sessionTicketLifeTime <positive_integer> -sessionTicketKeyRefresh ( ENABLED | DISABLED )] -sessionTicketKeyLifeTime <positive_integer> [-prevSessionTicketKeyLifeTime <positive_integer>]
<!--NeedCopy-->

Argumente:

SessionTicket: Verwenden Sie Session-Tickets wie in RFC 5077 beschrieben. Für die Einrichtung des ersten Handshakes sind CPU-intensive Verschlüsselungsvorgänge mit öffentlichen Schlüsseln erforderlich. Mit der Einstellung ENABLED gibt ein Server ein Sitzungsticket an einen Client aus, mit dem der Client einen abgekürzten Handshake ausführen kann.

Mögliche Werte: ENABLED, DISABLED. Standard: DISABLED

SessionTicketLifetime: Lebensdauer des Sitzungstickets in Sekunden. Nach Ablauf dieser Zeit können Clients dieses Ticket nicht verwenden, um ihre Sitzungen fortzusetzen.

Maximalwert: 172800 Mindestwert: 0. Standard: 300.

SessionTicketKeyRefresh: Wenn die Zeit abläuft, die durch den Parameter der Lebenszeit des Sitzungsticketschlüssels angegeben wird, generieren Sie den Sitzungsticketschlüssel, der zum Verschlüsseln oder Entschlüsseln der Sitzungstickets verwendet wird. Automatisch aktiviert, wenn SessionTicket aktiviert ist. Deaktiviert, wenn ein Administrator die Sitzungs-Ticket-Daten eingibt.

Mögliche Werte: ENABLED, DISABLED. Standard: ENABLED

SessionKeyLifetime: Die Lebensdauer eines symmetrischen Schlüssels, der zum Verschlüsseln der von einer Citrix ADC Appliance ausgestellten Sitzungstickets in Sekunden verwendet wird.

Maximalwert: 86400 Mindestwert: 600 Standard: 3000

PrevSessionKeyLifetime: Zeit in Sekunden, für die der vorherige symmetrische Schlüssel, der zum Verschlüsseln von Sitzungstickets verwendet wird, für bestehende Clients gültig bleibt, nachdem die Gültigkeitsdauer des Sitzungsticketschlüssels abgelaufen ist. Innerhalb dieser Zeit können vorhandene Clients ihre Sitzungen mit dem vorherigen Sitzungsticketschlüssel fortsetzen. Sitzungstickets für neue Clients werden mithilfe des neuen Schlüssels verschlüsselt.

Maximalwert: 172800 Mindestwert: 0. Standard: 0

Beispiel:

set ssl profile ns_default_ssl_profile_frontend -sessionTicket ENABLED -sessionTicketlifeTime 120 -sessionTicketKeyRefresh ENABLED -sessionTicketKeyLifeTime 100 -prevSessionTicketKeyLifeTime 60

Done

show ssl profile ns_default_ssl_profile_frontend

    Session Ticket: ENABLED
    Session Ticket Lifetime: 120 (secs)
    Session Key Auto Refresh: ENABLED
    Session Key Lifetime: 100 (secs)
    Previous Session Key Lifetime: 60 (secs)
<!--NeedCopy-->

Konfigurieren von SSL-Session-Ticket-Daten mit der GUI

1. Navigieren Sie zu System > Profileund wählen Sie SSL-Profilaus.

2. Wählen Sie ns_default_ssl_profile_frontend und klicken Sie auf Bearbeiten.

3. Klicken Sie im Abschnitt Grundeinstellungen auf das Stiftsymbol und legen Sie die folgenden Parameter fest:

   • Sitzungsticket
   • Sitzungs-Ticket-Lebensdauer (Sekunden)
   • Automatische Aktualisierung des Sitzungsticketschlüssels
   • Lebensdauer des Sitzungsticketschlüssels (Sekunden)
   • Lebensdauer des vorherigen Sitzungsticketschlüssels (Sekunden)

4. Klicken Sie auf OK.

Geben Sie SSL-Sitzungsticketdaten manuell mit der CLI ein

Geben Sie an der Eingabeaufforderung Folgendes ein:

set ssl profile <name> -sessionTicket ENABLED

set ssl profile <name> -sessionTicketKeyData

show ssl profile ns_default_ssl_profile_frontend
<!--NeedCopy-->

Argumente:

SessionTicket: Verwendung von Session-Tickets wie in RFC 5077 beschrieben. Für die Einrichtung des ersten Handshakes sind CPU-intensive Verschlüsselungsvorgänge mit öffentlichen Schlüsseln erforderlich. Mit der Einstellung ENABLED gibt ein Server ein Sitzungsticket an einen Client aus, mit dem der Client einen abgekürzten Handshake ausführen kann.

Mögliche Werte: ENABLED, DISABLED. Standard: DISABLED

sessionTicketKeyData: Contains the session ticket name (0–15 bytes), the session AES key used to encrypt or decrypt the session ticket (16–31 bytes), and the session HMAC key used to compute the digest of the ticket (32–63 bytes). Externally generated by an administrator and added to a Citrix ADC appliance.

Maximale Länge: 64 Byte

Beispiel:

set ssl profile ns_default_ssl_profile_frontend -sessionTicket ENABLED

Done

set ssl profile ns_default_ssl_profile_frontend -sessionTicketKeyData 111111111111111111111111111111111111111111111111

Done

show ssl profile ns_default_ssl_profile_frontend

    1) Name: ns_default_ssl_profile_frontend (Front-End)
    SSLv3: ENABLED TLSv1.0: ENABLED TLSv1.1: ENABLED TLSv1.2: ENABLED
    Client Auth: DISABLED
    Use only bound CA certificates: DISABLED
    Strict CA checks: NO
    Session Reuse: ENABLED Timeout: 120 seconds
    DH: DISABLED
    DH Private-Key Exponent Size Limit: DISABLED Ephemeral RSA: ENABLED Refresh Count: 0
    Deny SSL Renegotiation ALL
    Non FIPS Ciphers: DISABLED
    Cipher Redirect: DISABLED
    SSL Redirect: DISABLED
    Send Close-Notify: YES
    Push Encryption Trigger: Always
    PUSH encryption trigger timeout: 1 ms
    SNI: DISABLED
    OCSP Stapling: DISABLED
    Strict Host Header check for SNI enabled SSL sessions: NO
    Push flag: 0x0 (Auto)
    SSL quantum size: 8 kB
    Encryption trigger timeout 100 mS
    Encryption trigger packet count: 45
    Subject/Issuer Name Insertion Format: Unicode
    Session Ticket: ENABLED
    Session Ticket Lifetime: 300 (secs)
    Session Key Auto Refresh: DISABLED
    Session Key Lifetime: 3000 (secs)
    Previous Session Key Lifetime: 0 (secs)
    Session Key Data: 84dad1afc6d56b0deeb0a7fd7f299a207e8d8c15cdd087a5684a11a329fd732e87a0535d90883
    47e8c181ba266f5c8838ae472cb3ab9255b683bf922fad32cee816c329989ef7cdeb278e93ac37882e3

    ECC Curve: P_256, P_384, P_224, P_521

    1) Cipher Name: DEFAULT Priority :4
    Description: Predefined Cipher Alias

    1) Internal Service Name (Front-End): nsrnatsip-127.0.0.1-5061
    2) Internal Service Name (Front-End): nskrpcs-127.0.0.1-3009
    3) Internal Service Name (Front-End): nshttps-::1l-443
    4) Internal Service Name (Front-End): nsrpcs-::1l-3008
    5) Internal Service Name (Front-End): nshttps-127.0.0.1-443
    6) Internal Service Name (Front-End): nsrpcs-127.0.0.1-3008
    7) Vserver Name: v1

Done
<!--NeedCopy-->

Geben Sie SSL-Sitzungsticketdaten manuell mit der GUI ein

1. Navigieren Sie zu System > Profileund wählen Sie SSL-Profilaus.

2. Wählen Sie ns_default_ssl_profile_frontend und klicken Sie auf Bearbeiten.

3. Klicken Sie im Abschnitt Grundeinstellungen auf das Stiftsymbol und legen Sie die folgenden Parameter fest:

   • Sitzungsticket
   • Schlüsseldaten des Sitzungstickets
   • Sitzungsticketschlüsseldaten bestätigen

4. Klicken Sie auf OK.

Unterstützung für Extended Master Secret in SSL-Handshake auf Citrix ADC Nicht-FIPS-Plattformen

Hinweis: Dieser Parameter wird in Version 13.0 build 61.x eingeführt.

Extended Master Secret (EMS) ist eine optionale Erweiterung des Transport Layer Security (TLS) -Protokolls. Es wird ein neuer Parameter hinzugefügt, der sowohl für Front-End- als auch Back-End-SSL-Profile gilt, um EMS auf der Citrix ADC Appliance zu unterstützen. Wenn der Parameter aktiviert ist und der Peer EMS unterstützt, verwendet die ADC-Appliance die EMS-Berechnung. Wenn der Peer EMS nicht unterstützt, wird die EMS-Berechnung nicht für die Verbindung verwendet, obwohl der Parameter auf der Appliance aktiviert ist. Weitere Informationen zu EMS finden Sie unter RFC 7627.

Hinweis: EMS gilt nur für Handshakes, die das TLS-Protokoll Version 1.0, 1.1 oder 1.2 verwenden.

Plattformunterstützung für EMS

• MPX- und SDX-Plattformen, die entweder Cavium N3-Chips oder Crypto-Karten von Intel Coleto Creek enthalten. Die folgenden Plattformen werden mit Intel Coleto-Chips ausgeliefert:
• MPX 5900
• MPX/SDX 8900
• MPX/SDX 26000
• MPX/SDX 26000-50S
• MPS/SDX 26000-100 G
• MPX/SDX 15000-50 G

Sie können auch den Befehl “show hardware” verwenden, um festzustellen, ob Ihre Appliance über Coleto (COL) - oder N3-Chips verfügt.

• MPX- und SDX-Plattformen ohne Krypto-Karten (nur Software).

• Nur-Software-Plattformen: VPX, CPX und BLX.

EMS kann auf den folgenden Plattformen nicht aktiviert werden:

• MPX 9700 FIPS- und MPX 14000 FIPS-Plattformen.

• MPX- und SDX-Plattformen mit Cavium N2-Krypto-Chips.

Wenn der Parameter aktiviert ist, versucht die ADC-Appliance, EMS in Verbindungen mit TLS 1.2, TLS 1.1 und TLS 1.0 zu verwenden. Die Einstellung hat keine Auswirkungen auf TLS 1.3 oder SSLv3 Verbindungen.

Damit EMS mit dem Peer ausgehandelt werden kann, aktivieren Sie die Einstellung für das SSL-Profil, das an den virtuellen Server (Frontend) oder den Dienst (Backend) gebunden ist.

Aktivieren von EMS mit der CLI

Geben Sie an der Eingabeaufforderung Folgendes ein:

set ssl profile <profile name> [-allowExtendedMasterSecret (YES | NO)]

Beispiele

set ssl profile ns_default_ssl_profile_frontend  -allowExtendedMasterSecret YES

set ssl profile ns_default_ssl_profile_backend  -allowExtendedMasterSecret YES
<!--NeedCopy-->

Die folgende Tabelle zeigt den Standardwert des allowExtendedMasterSecret Parameters in verschiedenen Standard- und benutzerdefinierten Profilen.

Aktivieren von EMS mit der GUI

1. Navigieren Sie zu System > Profile > SSL-Profil.
2. Fügen Sie ein Profil hinzu oder bearbeiten Sie ein Profil.

3. Setzen Sie Extended Master Secret zulassen auf YES.

Unterstützung für die Verarbeitung der ALPN-Erweiterung in der Client-Hallo-Nachricht

Hinweis: Diese Funktion wird in Version 13.0 Build 61.x und höher unterstützt.

Den Front-End-SSL-Profilen alpnProtocol wird ein Parameter hinzugefügt, um das Anwendungsprotokoll in der ALPN-Erweiterung für die vom virtuellen SSL_TCP-Server bearbeiteten Verbindungen auszuhandeln. Nur das im SSL-Profil angegebene Protokoll wird ausgehandelt, wenn das gleiche Protokoll in der ALPN-Erweiterung der Client-Hallo-Nachricht empfangen wird.

Hinweis: Der Parameter alpnProtocol wird nur auf Front-End-SSL-Profilen unterstützt und gilt für SSL-Verbindungen, die von virtuellen Servern vom Typ SSL_TCP verarbeitet werden.

Festlegen des Protokolls im Front-End-SSL-Profil über die CLI

Geben Sie an der Eingabeaufforderung Folgendes ein:

set ssl profile ns_default_ssl_profile_frontend -alpnProtocol <protocol_name>

Der Parameter alpnProtocol kann drei Werte annehmen. Maximale Länge: 4096 Byte.

• NONE: Die Verhandlung über das Anwendungsprotokoll findet nicht statt. Dies ist die Standardeinstellung.
• HTTP1: HTTP1 kann als das Anwendungsprotokoll ausgehandelt werden.
• HTTP2: HTTP2 kann als das Anwendungsprotokoll ausgehandelt werden.

Beispiel:

set ssl profile ns_default_ssl_profile_frontend -ALPNProtocol HTTP2
> sh ssl profile ns_default_ssl_profile_frontend
1)  Name: ns_default_ssl_profile_frontend   (Front-End)
    SSLv3: DISABLED TLSv1.0: ENABLED  TLSv1.1: ENABLED  TLSv1.2: ENABLED  TLSv1.3: DISABLED
    Client Auth: DISABLED
    Use only bound CA certificates: DISABLED
    Strict CA checks:   NO
    Session Reuse: ENABLED  Timeout: 120 seconds
    DH: DISABLED
    DH Private-Key Exponent Size Limit: DISABLED    Ephemeral RSA: ENABLED  Refresh Count: 0
    Deny SSL Renegotiation  ALL
    Non FIPS Ciphers: DISABLED
    Cipher Redirect: DISABLED
    SSL Redirect: DISABLED
    Send Close-Notify: YES
    Strict Sig-Digest Check: DISABLED
    Zero RTT Early Data: DISABLED
    DHE Key Exchange With PSK: NO
    Tickets Per Authentication Context: 1
    Push Encryption Trigger: Always
    PUSH encryption trigger timeout:    1 ms
    SNI: DISABLED
    OCSP Stapling: DISABLED
    Strict Host Header check for SNI enabled SSL sessions:  NO
    Match HTTP Host header with SNI:    CERT
    Push flag:  0x0 (Auto)
    SSL quantum size:   8 kB
    Encryption trigger timeout  100 mS
    Encryption trigger packet count:    45
    Subject/Issuer Name Insertion Format:   Unicode

    SSL Interception: DISABLED
    SSL Interception OCSP Check: ENABLED
    SSL Interception End to End Renegotiation: ENABLED
    SSL Interception Maximum Reuse Sessions per Server: 10
    Session Ticket: DISABLED
    HSTS: DISABLED
    HSTS IncludeSubDomains: NO
    HSTS Max-Age: 0
    HSTS Preload: NO
    Allow Extended Master Secret: NO
    Send ALPN Protocol: HTTP2

 Done
 <!--NeedCopy-->

Legen Sie das Protokoll im Front-End-SSL-Profil mit der GUI fest

1. Navigieren Sie zu System > Profileund wählen Sie SSL-Profilaus.

2. Wählen Sie ns_default_ssl_profile_frontend und klicken Sie auf Bearbeiten.

3. Wählen Sie in der Liste ALPN-Protokoll die Option HTTP2 aus.

Laden einer alten Konfiguration

Das Aktivieren der Standardprofile ist nicht reversibel. Wenn Sie jedoch entscheiden, dass für die Bereitstellung die Standardprofile nicht erforderlich sind, können Sie eine ältere Konfiguration laden, die Sie gespeichert haben, bevor Sie die Standardprofile aktivieren. Die Änderungen sind wirksam, nachdem Sie die Appliance neu gestartet haben.

Laden einer alten Konfiguration mit der CLI

Geben Sie an der Eingabeaufforderung Folgendes ein:

shell

root@ns# clear config

root@ns# cd /nsconfig

root@ns# cp ns.conf.NS.11.0.jun.16 ns.conf

root@ns# reboot
<!--NeedCopy-->