Security – Part II

Networks such as the Internet (World Wide Web) as well as the intranet (local network/WLAN) can no longer be imagined without the protection of data connections . Almost everyone has heard the names of the protocols used for security. However, it is probably not clear to everyone what the difference between SSL, TLS and HTTPS is and what security properties these protocols have.


Why is a secure data connection useful?

Let’s assume a user wants to navigate to an exhibit in NeuroomNet. When using a secure connection, this user benefits from the security features of encrypted and secure communication. Without encryption, data that is transmitted can be read as plain text by anyone with access to the relevant network. With the increasing spread of open (ie unencrypted) WLANs, the importance of HTTPS increases because it allows content to be encrypted independently of the network used. The encryption makes it impossible for third parties, among other things, to see exactly which pages of a website have been visited.

The use of certificates ensures that no manipulation of the content by third parties is possible during transmission and, for example, no incorrect information about your company is injected into your company website.

The most important protocols for securing data connections for website and web application operators

SSL stands for Secure Sockets Layer, was designed by Netscape and first released with their browser in 1994 along with HTTPS. The development was continued until version 3.0. Weaknesses in SSL are known today and the protocol should therefore no longer be used.

TLS stands for Transport Layer Security and is the successor protocol to SSL 3.0. The first version 1.0 of TLS is a slightly modified variant of the third version of SSL and was standardized by the IETF. The Internet Engineering Task Force ( IETF , English for “Internet Engineering Working Group”) is an organization that deals with the technical advancement of the Internet in order to improve its functioning. Currently TLS is in version 1.3 and meanwhile also well spread.

TLS consists of two main components: TLS Handshake and TLS Record. A secure key exchange and authentication take place in the TLS handshake. TLS Record then uses the symmetric key negotiated in the TLS handshake for secure data transmission – the data is encrypted and protected against changes with a MAC.

MAC stands for Message Authentication Code (message authentication code in German) and is used to obtain certainty about the origin of data or messages and to check their integrity. MAC algorithms require two input parameters, firstly the data to be protected and secondly a secret key, and use both to calculate a checksum, the message authentication code.

A notice: SSL is the more common term these days, and when people talk about SSL, TLS is often meant.

HTTPS stands for Hypertext Transfer Protocol Secure (English for “secure hypertext transmission protocol”) and is a communication protocol in the network with which data can be transmitted securely. It represents a transport encryption.

HTTPS is used to establish confidentiality and integrity in the communication between NeuroomNet Server and web browser (client) on the network. HTTPS denotes the use of HTTP over SSL (TLS). The use of HTTPS can be recognized in the browser by the fact that the visited Internet address is prefixed with https instead of http . In addition, most modern browsers visually highlight a secure connection.

A secure connection is often equated with encrypting the connection. However, SSL/TLS offers additional security features.

According to the original design, the client browser should first display the certificate to the user after selecting the HTTPS address. The user then decides whether to trust the certificate for this session or whether to save it permanently, possibly after checking the links provided. Otherwise the HTTPS connection will not be established (“Leave this page” for Firefox or “Click here to leave this page.” for Internet Explorer).

The three main goals when using SSL/TLS are

  • confidentiality (through encryption),
  • data integrity and
  • authenticity .

These three objectives are explained below.


Confidentiality is guaranteed by encrypting the connection. This guarantees the user that his access data and control information, for example, cannot be intercepted and misused by third parties. It also protects all your data in NeuroomNet and thus forms the basis for compliance with the European GDPR.


Ensuring the integrity of the data guarantees that the controller cannot be manipulated. The user would probably not be very happy if instead of a turn on- he issued a delete command, for example, and the museum resents the cost and hassle of restoring it in such a case. It is even more unpleasant when someone else takes over the entire control and thus causes great damage, even one that threatens the existence of the company.


Authenticity means that the identity of the museum operator can be verified by the user. By ensuring the identity of the museum, the user knows exactly who they are communicating with. Criminals can exploit a lack of authenticity, for example, by registering domain names that closely resemble a museum’s domain and providing a copy of the controller under those domains. The potential customer can now be lured to the fake site via a phishing e-mail and, with an unsecured website, cannot tell directly whether he has landed at the right museum. He may enter his access data and someone else can now head for the right museum without hindrance.

Authentication is used so that both sides of the connection can check the identity of the connection partner when establishing communication.

Secure connections in practice

An SSL/TLS certificate is required to establish a secure connection. Among other things, the issuer of the certificate, the certificate holder and the public key of the certificate holder are stored in a certificate. Certificates are stored on the server with which a secure connection is to be established later. To ensure the integrity of a certificate, it is signed.

A security certificate can be generated and signed by anyone. However, in the case of self-signed certificates, there is no authenticity for third parties, since no independent institution has checked the identity of the issuer. Most browsers therefore display a warning message for websites with self-signed certificates. To verify the authenticity of a website or web application, a chain of trust is formed between the end user’s browser and the server of the website visited. The browser and operating system manufacturers check and trust selected organizations whose certificates are then stored in the browser or operating system. These organizations are also called certification bodies. The certification authorities can verify the identity of third parties and sign their certificates after verification. To ensure that a minimum standard is observed during the review, the organizations classified as trustworthy first go through a certification process. When visiting a website or using a web application, it is finally checked whether the chain of trust is intact.

There are different levels for verifying identity, which differ in the scope of the verification. At the lowest level (class 1), it is only checked whether the applicant owns the domain noted in the certificate. For Class 2 certificates, the identity of the applicant (individual or company) is verified more closely, for example with copies of identification documents and company documents. In the case of class 3 certificates, the verification is even more intensive and additional documents are required. Class 3 certificates are also referred to as extended validation certificates and are characterized, among other things, by the fact that the use in modern browsers is clearly highlighted.

Recommendations for using HTTPS

When transferring sensitive data, the use of an SSL/TLS certificate signed by a certification authority is always mandatory. If only a personal login area is to be protected, a self-signed certificate or a certificate signed by the hosting provider may be sufficient. In the case of self-signed certificates, however, the issuing certification authority must also be stored as trustworthy for the client so that there are no warning messages from the browser. These settings can be made by IT experts. Setting up a network-wide PKI structure is possible under both Linux and Windows. If there is no suitable IT expert/administrator on site, NeuroomNet can also provide suitable experts and even take over the maintenance. If necessary, these experts clarify the necessary documents for obtaining external certificates and then set them up. Internal certificates can have very long terms, while external certificates have to be renewed after just one year.

Notes on Authenticity

In theory, authenticity is given when using SSL/TLS certificates, but in practice there are problems with authenticity and whether you can trust the identity of the operator of a website must be decided on a case-by-case basis. On the one hand, Level 1 certificates are usually awarded automatically. This means that valid certificates can also be purchased for typo domains, which are often used for phishing attacks. On the other hand, authenticity stands and falls with trust in the work of the certification bodies. If there is only one certification authority that does not work properly when checking the authenticity of the applicant’s documents or ignores name similarities with other companies, it is possible for criminals to have certificates signed for companies with which they actually have nothing to do.


The digital certificate for SSL/TLS, which enables authentication, must be provided by the server: A binary document, which is generally issued by a certification authority (CA, itself certified), which uniquely identifies the server and the domain . An issued certificate always provides information about the issuer (certification authority) and the person who applied for the certificate (e.g. the web server and its operator).

When applying, the address data and the company name of the applicant are checked.

Certificate Authority (CA)

In information security, a certification authority (or CA for short) is an organization that issues digital certificates. A digital certificate is used to associate a specific public key with a person or organization. This mapping is authenticated by the certification authority by providing it with its own digital signature.


Digital certificates contain “keys” and supporting information that are used to authenticate, encrypt, and decrypt confidential data sent over the Internet and other networks. The additional information included, for example, is the period of validity, references to certificate revocation lists, etc., which are included in the certificate by the CA.


The task of a certification authority is to issue and verify these digital certificates. It is responsible for the provision, assignment and integrity assurance of the certificates it issues. It thus forms the core of the public key infrastructure.


A certificate authority can be a special company or an institution within a company that has its own server installed (e.g. with OpenSSL/Corporate PKI from Microsoft). Public organizations or government agencies can also serve as certification bodies, for example the Federal Network Agency in Germany.


In Germany, additional statutory requirements must be met for the issuance of advanced electronic certificates in accordance with Section 2 Number 2 Signature Act (SigG) or for qualified electronic signatures in accordance with Section 2 Number 3 Signature Act. In particular, the issuers of the certificates are subject to the supervision of the Federal Network Agency in order to guarantee the reliability and integrity of these certificates in legal transactions. For example, the applicant for such a signature must identify himself personally at an approved authority with his identity card so that such an electronic certificate can be issued to him. The data centers operated by the exhibitors must be particularly secure and thus meet high security requirements.


PKI stands for Public-Key-Infrastructure (German, infrastructure for public keys) and is used in cryptology to describe a system that can issue, distribute and check digital certificates. The certificates issued within a PKI are used to secure computer-aided communication.

Today’s security in companies relies on multi-level systems so that the top certification authority and its private key cannot be compromised (i.e. read out and misused by crooks or malicious people).

key (cryptology)

In cryptology, a key is a piece of information that parameterizes a cryptographic algorithm and controls it in this way.

In modern, computer-based symmetric and also asymmetric methods, the key is a bit sequence.

The key is the central component for decrypting a ciphertext and thus obtaining the plaintext.

Key for symmetrical methods

With symmetric processes, i.e. with all classic methods of cryptography and also with modern algorithms such as the Data Encryption Standard (DES) or its successor, the Advanced Encryption Standard (AES), both communication partners use the same (secret) key for both encryption and decryption also for decryption. While classic methods, in which the text has to be encrypted (i.e. encrypted and/or decrypted) by hand, almost always use a password as the key, the key in modern, i.e. computer-based, symmetrical processes usually consists of a bit sequence.

The security of a procedure depends not only on the algorithm itself but also on the key length. If an attack is found against a method that is more efficient than the brute force method, trying all possible keys, the method is considered broken. In a secure process, the key length directly indicates the level of security.


Key in asymmetric procedures

Asymmetric methods, such as the RSA cryptosystem, use key pairs consisting of a public key and a private (secret) key.

The public key is not secret, it should be known to other users, for example through distribution via key servers or certification authorities. It can be used to carry out public operations, i.e. to encrypt messages or check digital signatures. It is important that a public key can be uniquely assigned to a user or company. If this is not the case, for example if a message is encrypted with another user’s public key, he can read the message even though it was not intended for him. To easily name keys, a fingerprint is used, which is a short hash value that uniquely identifies a key.

In order to decrypt a ciphertext again or to sign a message, the private key is required. In contrast to symmetrical processes, in which several users share a secret key, only one user/company has the private (secret) key in the asymmetric process. This circumstance makes it possible to clearly assign a signature to a user/company. Therefore, it is fundamental that the private key cannot be derived from the public one.