| Beschreibung | Der Funktionsbaustein öffnet und schließt einen TLS-Socket, der für die sichere IP-Kommunikation zwischen einem Server und einem Client über TLS (Transport Layer Security) verwendet wird.Der TLS-Socket wird durch den Ausgangsparameter HANDLE repräsentiert. Dieses Handle muss an die Funktionsbausteine TLS_SEND und TLS_RECEIVE übergeben werden. Die FBs benötigen das Sockethandle für den sicheren Datenaustausch mit einem Kommunikationspartner.Mit einer steigenden Flanke am Eingang ACTIVATE wird begonnen, einen Socket zu öffnen. Bei erfolgreichem Öffnen des Sockets und Verbindungsaufbau wird der Ausgang ACTIVE auf TRUE gesetzt. Solange ACTIVE = TRUE ist, kann das Sockethandle am Ausgang HANDLE für den Aufruf der Funktionsbausteine TLS_SEND/ TLS_RECEIVE verwendet werden.
Eine fallende Flanke an ACTIVATE schließt den Socket. Die Verbindung wird mittels eines Drei-Wege-Handshake beendet, d.h. es werden drei Telegramme zwischen Client und Server ausgetauscht. Während des Beendungsprozesses führt eine erneute steigende Flanke zu einem Bausteinfehler.Der Eingang START_TLS legt fest, ob für den Datenaustausch über die Funktionsbausteine TLS_SEND und TLS_RECEIVE eine reine TCP-Verbindung oder eine TLS-Verbindung verwendet wird. Im typischen Anwendungsfall für den FB TLS_SOCKET liegt am Eingang START_TLS der Wert TRUE an, wenn der ACTIVATE-Eingang TRUE wird. In selteneren Fällen, wie zum Beispiel bei SMTP, wird an START_TLS eine steigende Flanke angelegt, während ACTIVATE auf TRUE gesetzt ist. Wenn nach erfolgreichem Verbindungsaufbau START_TLS = FALSE ist, verwenden die Funktionsbausteine TLS_SEND und TLS_RECEIVE eine TCP-Verbindung, um Daten zu senden bzw. zu empfangen. Die Eingänge SEND_SECURE bzw. RECEIVE_SECURE der Funktionsbausteine müssen dem Wert an START_TLS entsprechen. Liegt nach erfolgreichem Verbindungsaufbau eine steigende Flanke an START_TLS an, wird das TLS-Protokoll initialisiert. Das bedeutet, das TLS-Protokoll wird aufsetzend auf dem TCP-Protokoll verwendet. Solange START_TLS = TRUE, erfolgt das Senden und Empfangen von Daten über eine TLS-gesicherte Verbindung. Für die Initialisierung des TLS-Protokolls werden die Daten aus dem CONNECT_INFO-Eingang verwendet, die zum Zeitpunkt der FB-Aktivierung anlagen. Die vordefinierte Struktur am Eingang CONNECT_INFO enthält unter anderem die im Vertrauensspeicher (TrustStore) und Identitätsspeicher (IdentityStore) der Geräte enthaltenen Zertifikate für die Authentifizierung. (Eine Beschreibung der Werte am CONNECT_INFO und wie Sie Zertifikate im WBM der Steuerung verwalten und verknüpfen finden Sie weiter unten im Thema.)Das Aufrufen der TLS_SEND/ TLS_RECEIVE-Funktionsbausteine mit dem Sockethandle während ACTIVE auf FALSE gesetzt ist, führt zu einem Fehler an den Funktionsbausteinen. Solange der ACTIVATE-Eingang gesetzt ist, bleibt der Socket geöffnet. Der Ausgang BUSY wird auf TRUE gesetzt, während ACTIVATE = TRUE und der Socket noch nicht geöffnet ist. Bei einer fallenden Flanke des ACTIVATE-Eingangs wird der Socket geschlossen und der Ausgang ACTIVE auf FALSE gesetzt (siehe hierzu auch die nachfolgenden Hinweise). Sollte eine erfolgreich aufgebaute Verbindung geschlossen werden, versucht der Funktionsbaustein diese Verbindung erneut aufzubauen (sofern ACTIVATE = TRUE bleibt).Der Eingang IS_SRV legt fest, ob der Funktionsbaustein eine Verbindung als TCP-Server oder TCP-Client aufbaut.
- Mit IS_SRV = TRUE erzeugt der Funktionsbaustein einen "horchenden" (listening) Socket (Server-Socket). Der Socket kann an einen lokalen Ethernet-Adapter (Angabe der IP-Adresse am Eingang BIND_IP) und einen Port (Eingang BIND_PORT) gebunden werden. Unter dieser IP-Adresse und Portnummer wartet anschließend der Server auf Anfragen der Clients- Falls erforderlich können die akzeptierten Clients über die Eingänge DEST_IP/DEST_PORTS limitiert werden. Bei geöffnetem (Server-) Socket sind nur 1:1 Verbindungen möglich. Das bedeutet, der Listening-Socket akzeptiert nur eine eingehende TLS-Verbindung.
- Mit IS_SRV = FALSE wird ein Client-Socket erzeugt. In diesem Fall legen DEST_IP/DEST_PORT die IP-Adresse und den Port des Partner-Servers fest, mit dem kommuniziert werden soll.
Unbeabsichtigter Betriebszustand des Geräts
Stellen Sie sicher, dass das Ändern der Ausgangsdaten nicht zu einem ungewollten oder gefährlichen Verhalten des Gesamtsystems führen kann. |
|
| Parameter | Eingänge
 ACTIVATE
| Datentyp: | BOOL |
| Beschreibung: | Bei einer steigenden Flanke am Eingang wird begonnen, den Socket zu öffnen. Solange der ACTIVATE-Eingang gesetzt ist, bleibt der Socket geöffnet. Bei einer fallenden Flanke wird der Socket geschlossen.Da das Schließen des Sockets einige Zeit in Anspruch nimmt (Drei-Wege-Handshake zwischen Client und Server), darf die nächste steigende Flanke erst an ACTIVATE anliegen, wenn die Ausgänge ACTIVE und BUSY beide FALSE sind.
Andernfalls (d.h. falls eine neue Verbindung angefordert wird, obwohl der vorherige Socket noch nicht vollständig geschlossen ist) führt dies zu einem Fehler und es wird der Fehlercode 16#C205 am STATUS-Ausgang ausgegeben. |
IS_SRV
| Datentyp: | BOOL |
| Beschreibung: | Legt fest, ob der Funktionsbaustein eine Server- oder Client-Funktion realisiert.TRUE: Der Funktionsbaustein erzeugt einen "horchenden" Socket (Server-Socket).FALSE: Der Funktionsbaustein erzeugt einen Client-Socket.Der Funktionsbaustein wertet diesen Parameter nur in dem Taskzyklus aus, in dem am ACTIVATE-Eingang eine steigende Flanke erkannt wird. |
BIND_IP
| Datentyp: | STRING |
| Beschreibung: |
- Für IS_SRV = TRUE gilt: Dieser Parameter gibt die IP-Adresse an, auf welcher der Server auf eingehende Verbindungen hört. Für Clients, die eine Verbindung zum Server herstellen möchten, muss am DEST_IP-Eingang dieselbe IP-Adresse angegeben werden. Wird ein leerer String (Anfangswert des Parameters) oder '0.0.0.0' angegeben, hört der Server über jeden Ethernet-Adapter der Steuerung.
- Für IS_SRV = FALSE gilt: In diesem Fall ist der Parameter optional. Falls spezifiziert, identifiziert er den Ethernet-Adapter der Steuerung, über den die Kommunikation erfolgen soll. Andernfalls (leerer String oder Wert '0.0.0.0'), wählt die Steuerung gemäß dem Parameter DEST_IP den passenden Ethernet-Adapter aus.
Der Funktionsbaustein wertet diesen Parameter nur in dem Taskzyklus aus, in dem am ACTIVATE-Eingang eine steigende Flanke erkannt wird. |
BIND_PORT
| Datentyp: | UINT |
| Beschreibung: | Gibt die lokale Portnummer an, an welchen der erzeugte Socket gebunden ist (notwendig zur Realisierung eines TLS-Servers). Die ausgewählte Portnummer wird vom TLS-Server für eingehende Daten verwendet. Für Clients, die eine Verbindung zum Server herstellen möchten, muss am DEST_PORT-Eingang dieselbe Portnummer angegeben werden. Ist der Wert 0 (Anfangswert des Parameters), wählt der Stack einen temporären Port aus.Der Funktionsbaustein wertet diesen Parameter nur in dem Taskzyklus aus, in dem am ACTIVATE-Eingang eine steigende Flanke erkannt wird. |
DEST_IP
| Datentyp: | STRING |
| Beschreibung: | Abhängig von der realisierten Funktion des FBs (Verwendung als Server oder Client; eingestellt über den Eingang IS_SRV), gilt folgendes:
- Mit IS_SRV = TRUE (der FB erzeugt einen horchenden Socket) werden nur Anfragen des Clients mit dieser IP-Adresse akzeptiert.
Wird ein leerer String (Anfangswert des Parameters) angegeben, wird jede Client-IP-Adresse akzeptiert.
- Mit IS_SRV = FALSE (FB erzeugt einen Client-Socket) definiert der Parameter die IP-Adresse des Partner-Servers, mit dem kommuniziert werden soll.
Der Funktionsbaustein wertet diesen Parameter nur in dem Taskzyklus aus, in dem am ACTIVATE-Eingang eine steigende Flanke erkannt wird. |
DEST_PORT
| Datentyp: | UINT |
| Beschreibung: | Abhängig von der realisierten Funktion des FBs (Verwendung als Server oder Client; eingestellt über den Eingang IS_SRV), gilt folgendes:
- Mit IS_SRV = TRUE (der FB erzeugt einen horchenden Socket) werden nur Anfragen des Clients mit diesem IP-Port akzeptiert.
Wird der Wert 0 (Anfangswert des Parameters) angegeben, wird jeder Client-IP-Port akzeptiert.
- Mit IS_SRV = FALSE (FB erzeugt ein Client-Socket) definiert der Parameter den IP-Port des Partner-Servers, mit dem kommuniziert werden soll.
Der Funktionsbaustein wertet diesen Parameter nur in dem Taskzyklus aus, in dem am ACTIVATE-Eingang eine steigende Flanke erkannt wird. |
CONNECT_INFO
| Datentyp: | ConnectInfo (vordefinierte Struktur) |
| Beschreibung: | Für die Initialisierung des TLS-Protokolls verwendete Attribute. Die Werte werden in dem Zyklus mit der steigenden Flanke am ACTIVATE-Eingang ausgelesen. Die ausgelesenen Werte werden verwendet, sobald am Eingang START_TLS der Wert TRUE anliegt.Die Struktur enthält die folgenden vordefinierten Elemente:
| Strukturelement | Datentyp | Beschreibung |
| TrustStoreName | STRING | Name des Vertrauensspeichers (TrustStore). Der TrustStore wird während der Kommunikation über SSL verwendet, um das Gegenstellenzertifikat zu prüfen. Mit den Informationen aus dem TrustStore kann der Server die Identität von Clients authentifizieren, die sich mit dem Server verbinden möchten. Er validiert dazu die Echtheit des Zertifikats, das jeder Client präsentiert.Die Vertrauensspeicher (TrustStores) und die enthaltenen Zertifikate können über das Web-based Management (WBM) der Steuerung verwaltet werden. So können Sie Zertifikate auch während des laufenden Betriebs austauschen, ohne das Anwendungsprogramm ändern zu müssen.Eine Beschreibung wie Sie im WBM der Steuerung Zertifikate des IdentityStores und TrustStores verwalten und verknüpfen finden Sie im unten stehenden Abschnitt "Zusatzinformationen".
Weitere Infos
Weitere Informationen zu den Zertifikaten für die sichere Kommunikation der Steuerung finden Sie im PLCnext Info Center. |
Hintergrundinformationen
Ein TrustStore ist ein (durch den TrustStore-Namen identifizierter) spezieller persistenter Speicherbereich, der Kriterien zum Verifizieren der Zertifikate enthält, mit denen sich die Kommunikationspartner authentifizieren. Das bedeutet, der Inhalt des TrustStore ermöglicht die Überprüfung der Echtheit eines Zertifikats, das ein potenzieller Kommunikationspartner vorzeigt.
|
| IdentityStoreName | STRING | Name des Identitätsspeichers (IdentityStore). Der IdentityStore enthält die Server-Zertifikate, zusammen mit einem privaten Schlüssel. Die Zertifikate werden zur Kommunikation über SSL zur Authentifizierung zwischen dem Server und den Clients verwendet.
Wenn der Server als TLS-Server verwendet wird, muss hier ein Wert angegeben werden. Der IdentityStore-Name muss beim Aufbau einer sicheren Verbindung zwingend vom Server angegeben werden.Die Identitätsspeicher (IdentityStores), die enthaltenen Zertifikate und Schlüsselpaare können über das Web-based Management (WBM) der Steuerung verwaltet werden. So können Sie Zertifikate auch während des laufenden Betriebs austauschen, ohne das Anwendungsprogramm ändern zu müssen.Eine Beschreibung wie Sie im WBM der Steuerung Zertifikate des IdentityStores und TrustStores verwalten und verknüpfen finden Sie im unten stehenden Abschnitt "Zusatzinformationen".
Weitere Infos
Weitere Informationen zu den Zertifikaten für die sichere Kommunikation der Steuerung finden Sie im PLCnext Info Center. |
Hintergrundinformationen
Ein IdentityStore ist ein (durch den IdentityStore-Namen identifizierter) spezieller persistenter Speicherbereich, der z.T. streng geheime Daten enthält, mit denen sich ein Gerät bei seinen Kommunikationspartnern identifizieren kann.
Die Daten beinhalten ein asymmetrisches Schlüsselpaar (bestehend aus dem öffentlichen und dem privaten Schlüssel). Dieses Schlüsselpaar geht einher mit einem entsprechenden Zertifikat zum öffentlichen Schlüssel (gem. dem Standard X.509) und optional auch mit Ausstellerzertifikaten bis hinauf zum Trusted Anchor (Wurzelzertifikat oder Anker für Vertrauensstellung).
Zur Authentifizierung nutzt das Gerät sein asymmetrisches Schlüsselpaar. Entweder betrachtet der Kommunikationspartner den öffentlichen Schlüssel als vertrauenswürdig (weil er dessen Identität kennt) oder das Gerät übermittelt zusätzlich sein Zertifikat (das seine Identität ausweist), welches der Kommunikationspartner dann verifiziert. In hierarchischen Zertifizierungsstrukturen muss das Gerät auch die in seinem IdentityStore hinterlegten Ausstellerzertifikate senden, damit der Kommunikationspartner den gesamten Zertifizierungspfad validieren kann.
|
| CipherList | STRING | Chiffrekombinationen, die für den Aufbau der sicheren TLS-Verbindung verwendet werden sollen.Ab Firmware-Version 2019.6 der Steuerung, verwendet der Funktionsbaustein die in der openSSL-Bibliothek implementierte Default Cipher Liste, wenn keine Cipher Liste angegeben wird. Bei älteren Firmware-Versionen müssen Sie eine nicht leere Cipher Liste angeben, da ansonsten keine TLS-Verbindung aufgebaut wird, wenn der FB ausgeführt wird.
Hintergrundinformationen
Ein Chiffre ist ein kryptographischer Algorithmus zum Ver- und Entschlüsseln von Informationen. Chiffren sind in Chiffrensammlungen (Cipher Suites) zusammengefasst. Die Cipher Suite bestimmt, welcher Algorithmus für den Aufbau der sicheren Verbindung verwendet werden soll. Das TLS-Protokoll unterstützt eine Vielzahl von Cipher Suites zur gegenseitigen Authentifizierung von Server und Client.
Im Rahmen der sicheren Verbindung einigen sich Server und Client über die zu verwendende Cipher Suite, je nachdem, welche Chiffren dem Client und dem Server jeweils für den Datenaustausch zur Verfügung stehen.
|
| HostName | STRING | Name der Gegenstelle; wird mit dem Namen des Gegenstellenzertifikats verglichen.
Der HostName wird für Clients verwendet und ist optional. Er erhöht die Sicherheit bei der Authentizitätsprüfung. |
|
START_TLS
| Datentyp: | BOOL |
| Beschreibung: | Legt fest, ob die Kommunikation über TCP oder TLS stattfindet. Nach einem erfolgreichen Verbindungsaufbau gilt folgendes:
- Bei START_TLS = FALSE verwenden die Funktionsbausteine TLS_SEND und TLS_RECEIVE eine reine TCP-Verbindung, um Daten zu senden bzw. zu empfangen.
- Bei START_TLS = TRUE wird das TLS-Protokoll initialisiert und die bestehende TCP-Verbindung wird durch eine TLS-Verbindung ersetzt. Das Senden und Empfangen von Daten erfolgt über eine TLS-gesicherte Verbindung.
Für die Initialisierung des TLS-Protokolls werden die zum Zeitpunkt der FB-Aktivierung am Eingang CONNECT_INFO anliegenden Daten verwendet (siehe oben).Das Wechseln von START_TLS auf FALSE bei geöffnetem TLS-Socket führt zu einem Fehler (Ausgang ERROR = TRUE), der am Ausgang STATUS mit dem Fehlercode 16#C151 angezeigt wird.
Hinweis
Der Wert für START_TLS wird mit dem Wert verglichen, der an den Eingängen SEND_SECURE bzw. RECEIVE_SECURE der Funktionsbausteine TLS_SEND bzw. TLS_RECEIVE anliegt. Werden Inkonsistenzen zwischen den Eingangswerten festgestellt, zum Beispiel bei SEND_SECURE = TRUE (IEC-Anwendung erfordert sichere Datenübertragung) und START_TLS = FALSE (TLS-Protokoll noch nicht initialisiert), geben die FBs TLS_SEND und TLS_RECEIVE einen Fehler aus (Ausgang ERROR = TRUE und Fehlercode 16#C150 am Ausgang STATUS). |
Hinweis
Das Zurücksetzen von START_TLS auf FALSE kann nicht zum Deaktivieren des TLS-Protokolls und Reaktivieren des TCP-Protokolls verwendet werden. Dies wird vom Baustein nicht unterstützt. |
|
Ausgänge
HANDLE
| Datentyp: | DWORD |
| Beschreibung: | Das erzeugte Handle des TLS-Sockets. Das Sockethandle wird als Input für die Funktionsbausteine TLS_RECEIVE und TLS_SEND benötigt, um bspw. Daten an einen TLS-Server zu senden bzw. von diesem zu empfangen.Das Sockethandle kann nur für einen Aufruf der Funktionsbausteine TLS_SEND und TLS_RECEIVE verwendet werden, solange ACTIVE = TRUE ist. Das Aufrufen eines TLS_*-Funktionsbausteins während ACTIVE = FALSE ist, führt zu einem Fehler (eine entsprechende Fehlermeldung wird am Ausgang STATUS der TLS_*-Funktionsbausteine ausgegeben). |
ACTIVE
| Datentyp: | BOOL |
| Beschreibung: | Zeigt an, ob ein Socket geöffnet ist.TRUE: Die Verbindung wurde erfolgreich aufgebaut und der Socket ist geöffnet. Solange ACTIVE = TRUE ist, kann das erzeugte Sockethandle (HANDLE-Eingang) von den Funktionsbausteinen TLS_SEND und TLS_RECEIVE verwendet werden, um Daten zu senden bzw. zu empfangen.FALSE: Der Socket ist geschlossen. Das Aufrufen der TLS_SEND/ TLS_RECEIVE-Funktionsbausteine mit dem Sockethandle während ACTIVE auf FALSE gesetzt ist, führt zu einem Fehler an den Funktionsbausteinen. |
BUSY
| Datentyp: | BOOL |
| Beschreibung: | Wird auf TRUE gesetzt, wenn der Eingang ACTIVE = TRUE ist und der Socket noch nicht geöffnet ist. Nach erfolgreichem Öffnen des Sockets wird BUSY auf FALSE gesetzt und bleibt FALSE, solange ACTIVE = TRUE ist. |
ERROR
STATUS
| Datentyp: | WORD |
| Beschreibung: | Liefert den Fehlercode im Fehlerfall (ERROR = TRUE) oder den aktuellen Status des Funktionsbausteins (ERROR = FALSE). Fehlercodes beginnen mit 16#Cxxx und Statuscodes mit 16#8xxx.Siehe Fehlercodes / Statuscodes für TLS*-Funktionsbausteine . |
USED_PORT
| Datentyp: | UINT |
| Beschreibung: | Zeigt den Port an, der für die Erzeugung des Sockets verwendet wird (entweder automatisch vergeben oder die am Eingang BIND_PORT angegebene Portnummer). Der Ausgang kann bei Bedarf für Diagnosezwecke verwendet werden. |
|
