Blog

Categories:

11. 5. 2026

Security Cryptography

SNI, ESNI/ECH and SSL inspection

Basic tools for communication and connection analysis are based on SSL inspection technologies and fingerprints of communication partners. But the arrival of ECH means an evolution in user privacy protection, including the impact on these tools. But how to understand it?

SNI as a current technology

Currently, SNI (Server Name Indication) is still used, which communicates the target hostname as part of ClientHello. This brings a huge advantage, because thanks to SNI, each server does not need to have a separate IP address. And virtualization saves not only IP addresses, but also costs in a huge way.

How does it work? The identification of the target server is sent as part of the ClientHello. Based on the given information, the target server can choose the corresponding virtual server and provide the relevant key material (certificate). So there can be tens to hundreds of virtual servers on one IP address. At the same time, this entry allows the various SSL inspection servers to appropriately verify whether the queried server address is accepted by the organizational policy or not.

Why inspection is so important

Communication inspection is today at the border points of the network one of the most powerful weapons against various computer viruses, fraud and other types of attacks, threatening the operation of the organization. The administrator is responsible for this network. Unfortunately, if you don't have control over the network, maintaining and managing it is almost impossible. The control mechanisms of anti-virus products, internet providers or at the borders of some state entities work in a similar way. Even here, however, there must be some reason for the analysis. This could be computer protection, network protection, or national interest protection. National interests also include combating crime, so in a developed society it is not possible to simply control someone. In the case of security forces, there must be an appropriate authorization for this, e.g. a court order. But that depends on the specific jurisdiction.

The arrival of ESNI / ECH and the differences between them

ESNI (Encrypted SNI) or even better ECH (Encrypted Hello) bring protection of transmitted information, each technology in a different way. ESNI is considered to be obsolete and currently support is emerging mainly for ECH. But what are the differences between them?

ESNI used encryption to only protect SNI as a single parameter. A list of ciphersuites, various extensions, including ALPN, remained visible and thus allowed TLS fingerprinting to be created. This can be useful in cooperation with IDS/IPS systems, as a protection mechanism against some types of attacks. However, ESNI does not address the leakage of this metadata and its exploitability. ECH, on the other hand, solves the complete protection of Client Hello. It is entirely encrypted, in the unencrypted part there is only a generic SNI, which serves as a fallback and contains minimal metadata. The encrypted part contains all other information, including data used for fingerprinting such as ciphersuites and ALPN type extensions. In such a case, it is almost impossible to use this metadata, or use it to protect the network infrastructure.

Using ECH has its advantages and disadvantages, which depend on the architecture of use. Among the properties of double meaning is the already mentioned limitation of the ability to detect a client machine by its metadata. This can be used to identify clients, but also, for example, to protect against botnets or other methods of attackers. Another issue is the limitation of TLS inspection capabilities, which is one of the necessary tools for traffic control and surveillance of network traffic. On the one hand, this technology increases privacy protection, while on the other hand, it limits the ability of administrators to protect users' data and work. This has major implications for security management.

There are only a few methods left in the case of ECH deployment. Firstly, the evaluation of the trustworthiness of IP addresses, which however completely fails in the case of CDN (Content Distributed Network), cloud environment or dynamic addressing. It is also possible to use evaluation and sessions for DNS queries, i.e. behavioral analysis. Outside of ECH, however, there is a problem with DNS query protection methods such as DoH (DNS over HTTPS), DoS (DNS over SSL) or DoQ (DNS over QUIC). In case of their availability, the administrator has no chance to control the network. The use of SSL inspection will be limited thanks to ECH, current systems will need to be upgraded to deal with the new architecture. The resolution of normal traffic due to the protected content of Client Hello (including fallback SNI) will thus be computationally more demanding. The last option is traffic monitoring, i.e. available data on the number of packets, their size, and communication times. That is, the analysis of metadata and behavior, which has a large number of limitations and the results will not be completely accurate.

The most reasonable method seems to me to be a form of SSL inspection, combined with forging the ECH record in DNS. At that point, the client connects to the inspection server, which, based on the client's query, connects to the source server. An alternative is to completely disable ECH in organizations, with the inspection server enabling ECH only from the inspection server. Relying on the fallback of cloud-hosted sites is problematic. The SNI record goes to the main domain by default, because fallback relies only on reported information. But this is completely insufficient for network management and control.

How ESNI works

An older variant of protection, ESNI, uses generated keys stored in DNS for the initial initialization of the protocol. The _esni text entry within the domain, was used for storage:

_esni.domain.tld TXT "BASE64_ENCODED_ESNI_CONFIG"

where the custom ESNI config in binary form contains the following data structure:

struct { uint16 version; uint8 checksum[4]; KeyShareEntry { uint16 group; // např. X25519 opaque public_key }; CipherSuite cipher_suites[]; uint64 not_before; uint64 not_after; uint16 extensions; } ESNIKeys;

On the basis of the obtained keys, a cryptogram is created using ECDH key agreement. Its creation proceeds in the following way. An ESNI extension will be created, containing information about the key material that will be provided to the server.

ESNIExtension = { cipher_suite; key_share (client ephemeral publickey); record_digest; encrypted_sni (ciphertext); }

Next, the shared key is calculated and the individual secrets are derived so that the data can be encrypted. Some of these secrets are written to the ESNI extenstion:

shared_secret = ECDH(ephemereal secret_key_klient, publickey_server) secret = HKDF-Extract(0, shared_secret) key = HKDF-Expand(secret, "esni key") nonce = HKDF-Expand(secret, "esni nonce") ciphertext = AEAD_Encrypt(key, nonce, SNI, associated_data)

Finally, it is possible to send information about the key material to the server. Based on the given information, he can decrypt the data and obtain the corresponding SNI from the ESNI:

ESNI payload = ephemeral_publickey_client || ciphertext

Why ESNI was replaced by ECH in a short time

ESNI proposals appeared as early as 2018 and were first deployed around 2020, but never reached the RFC stage. The reason for the creation of ESNI was unencrypted SNI, allowing censorship and surveillance. So the dark side of network traffic management. Unfortunately, during the trials, the inadequacy of the design became apparent, i.e. too narrow a protection. From 2020, there were changes in the proposal until today, in the form of ECH. From 2023, RFC 9320, RFC 9337 and RFC 9361 were gradually standardized, which describe how ECH should solve the problem of protection against tracking.

How ECH works

For ECH, the situation is slightly different from ESNI. This technology abandoned the use of TXT records, due to problems with extensibility and versioning. Therefore, HTTPS (RR type 65) and SVCB (Service Binding) records are used for configuration. An example of such a record can be, for example:

domain.tld. HTTPS 1. alpn="h2,h3" ech="BASE64_ENCODED_ECH_CONFIG"

The ech="BASE64" entry is important in this entry. This contains a configuration that has the structure
ECHConfig = { version public_name max_name_length key_config { kem_id public_key cipher_suites config_id } }

In the beginning, it is necessary for the server to generate its private and public key. The public key is stored in the DNS record, the private key does not leave the server. When initializing the connection, the client generates its pair of keys, where it provides the public key to the server and keeps the private key. Thanks to the use of ECDH, both parties can agree on a shared secret.

shared_secret = ECDH(ephemeral secret_key_client, publickey_server) key = HKDF-Expand(secret, "ech key") nonce = HKDF-Expand(secret, "ech nonce") associated_data = outer ClientHello, config_id, encapsulated_key ciphertext = AEAD_Encrypt(key, nonce, ClientHelloInner, associated_data)

Next, a connection header is created where the encrypted ECH is of the following form. A possible attacker should not be able to see any relevant data. The question is what address will be used for fallback (SNI) and whether DNS queries will be correlated with the connection.

ECHCiphertext = (ephemeral public_key_client, ciphertext )

If OpenSSL 4.0 is installed, approximately the following procedure can be used. The latter assumes the use of the following ciphersuite.

KEM : X25519 = 0x0020 KDF : HKDF-SHA256 = 0x0001 AEAD: AES-256-GCM = 0x0002

Procedure:
mkdir -p /home/git cd /home/git git --clone https://github.com/defo-project/ech-dev-utils mkdir -p /home/git/ech openssl ech -public_name domain.tld -suite x25519,hkdf-sha256,aes256gcm -out /home/git/ech/domain.tld.pem.ech /home/git/ech-dev-utils/scripts/pem2rr.sh /home/git/ech/domain.tld.pem.ech

where the output is the string BASE64_CONFIG. It must then be processed into a format that can be used for HTTSP recording.

ech-enabled-portal.domain.tld. 3600 IN HTTPS 1 . alpn="h2,h3" ech="BASE64_CONFIG"

In addition to the mentioned record, it is necessary to have a record referring to the IP address both for the domain or some default web server, and for the ech-enabled-portal. In the case of connecting to the portal, an SNI referring directly to the domain's default server will be provided, even though the client will be using a different server.

Other settings already depend only on web server configurations. The question here will be how to solve possible access control in the network. For most systems, such a configuration makes no sense. An example is news and similar sites. In the second situation, I can imagine websites where said hiding of information can be important.

ECH is a good servant but a bad master. Too benevolent management can not only let visitors into the network that you do not know about. But it will be possible to exfiltrate data through it in the same way. Therefore, it will be necessary to consider when such use will be acceptable and when it will be necessary to prohibit it.

Reference:

Draft Encrypted Server Name Indication for TLS 1.3
Source: https://ietf.org/
Good-bye ESNI, hello ECH!
Source: https://blog.cloudflare.com/
RFC 9849 TLS Encrypted Client Hello
Source: https://www.rfc-editor.org/
OpenSSL 4.0 Documentation
Source: https://docs.openssl.org/
Quick set up guide for Encrypted Client Hello (ECH)
Source: https://guardianproject.info/
GIT defo-project/ech-dev-utils
Source: https://github.com/

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.

1. Introductory Provisions

1.1. These General Terms and Conditions are, unless otherwise agreed in writing in the contract, an integral part of all contracts relating to training organised or provided by the trainer, Jan Dušátko, IČ 434 797 66, DIČ 7208253041, with location Pod Harfou 938/58, Praha 9 (next as a „lector“).
1.2. The contracting parties in the general terms and conditions are meant to be the trainer and the ordering party, where the ordering party may also be the mediator of the contractual relationship.
1.3. Issues that are not regulated by these terms and conditions are dealt with according to the Czech Civil Code, i.e. Act No.89/2012 Coll.
1.4. All potential disputes will be resolved according to the law of the Czech Republic.

2. Creation of a contract by signing up for a course

2.1. Application means unilateral action of the client addressed to the trainer through a data box with identification euxesuf, e-mailu with address register@cryptosession.cz or register@cryptosession.info, internet pages cryptosession.cz, cryptosession.info or contact phone +420 602 427 840.
2.2. By submitting the application, the Client agrees with these General Terms and Conditions and declares that he has become acquainted with them.
2.3. The application is deemed to have been received at the time of confirmation (within 2 working days by default) by the trainer or intermediary. This confirmation is sent to the data box or to the contact e-mail.
2.4. The standard time for registration is no later than 14 working days before the educational event, unless otherwise stated. In the case of a natural non-business person, the order must be at least 28 working days before the educational event.
2.5. More than one participant can be registered for one application.
2.6. If there are more than 10 participants from one Client, it is possible to arrange for training at the place of residence of the intermediary or the Client.
2.7. Applications are received and processed in the order in which they have been received by the Provider. The Provider immediately informs the Client of all facts. These are the filling of capacity, too low number of participants, or any other serious reason, such as a lecturer's illness or force majeure. In this case, the Client will be offered a new term or participation in another educational event. In the event that the ordering party does not agree to move or participate in another educational event offered, the provider will refund the participation fee. The lack of participants is notified to the ordering party at least 14 days before the start of the planned term.
2.8. The contract between the provider and the ordering party arises by sending a confirmation from the provider to the ordering party.
2.9. The contract may be changed or cancelled only if the legal prerequisites are met and only in writing.

3. Termination of the contract by cancellation of the application

3.1. The application may be cancelled by the ordering party via e-mail or via a data mailbox.
3.2. The customer has the right to cancel his or her application for the course 14 days before the course takes place without any fees. If the period is shorter, the subsequent change takes place. In the interval of 7-13 days, an administrative fee of 10% is charged, cancellation of participation in a shorter interval than 7 days then a fee of 25%. In case of cancellation of the application or order by the customer, the possibility of the customer's participation in an alternative period without any additional fee is offered. The right to cancel the application expires with the implementation of the ordered training.
3.3. In case of cancellation of the application by the trainer, the ordering party is entitled to a full refund for the unrealized action.
3.4. The ordering party has the right to request an alternative date or an alternative training. In such case, the ordering party will be informed about all open courses. The alternative date cannot be enforced or enforced, it depends on the current availability of the course. If the alternative training is for a lower price, the ordering party will pay the difference. If the alternative training is for a lower price, the trainer will return the difference in the training prices to the ordering party.

4. Price and payment terms

4.1. By sending the application, the ordering party accepts the contract price (hereinafter referred to as the participation fee) indicated for the course.
4.2. In case of multiple participants registered with one application, a discount is possible.
4.3. The participation fee must be paid into the bank account of the company held with the company Komerční banka č. 78-7768770207/0100, IBAN:CZ5301000000787768770207, BIC:KOMBCZPPXXX. When making the payment, a variable symbol must be provided, which is indicated on the invoice sent to the client by the trainer.
4.4. The participation fee includes the provider's costs, including the training materials. The provider is a VAT payer.
4.5. The client is obliged to pay the participation fee within 14 working days of receipt of the invoice, unless otherwise stated by a separate contract.
4.6. If the person enrolled does not attend the training and no other agreement has been made, his or her absence is considered a cancellation application at an interval of less than 7 days, i.e. the trainer is entitled to a reward of 25% of the course price. The overpayment is returned within 14 days to the sender's payment account from which the funds were sent. Payment to another account number is not possible.
4.7. An invoice will be issued by the trainer no later than 5 working days from the beginning of the training, which will be sent by e-mail or data box as agreed.

5. Training conditions

5.1. The trainer is obliged to inform the client 14 days in advance of the location and time of the training, including the start and end dates of the daily programme.
5.2. If the client is not a student of the course, he is obliged to ensure the distribution of this information to the end participants. The trainer is not responsible for failure to comply with these terms and conditions.
5.2. By default, the training takes place from 9 a.m. to 5 p.m. at a predetermined location.
5.3. The trainer can be available from 8 a.m. to 9 a.m. and then from 17 a.m. to 6 p.m. for questions from the participants, according to the current terms and conditions.
5.4. At the end of the training, the certificate of absorption is handed over to the end users.
5.5. At the end of the training, the end users evaluate the trainer's approach and are asked to comment on the evaluation of his presentation, the manner of presentation and the significance of the information provided.

6. Complaints

6.1. If the participant is grossly dissatisfied with the course, the trainer is informed of this information.
6.2. The reasons for dissatisfaction are recorded in the minutes in two copies on the same day. One is handed over to the client and one is held by the trainer.
6.3. A statement on the complaint will be submitted by e-mail within two weeks. A solution will then be agreed within one week.
6.4. The customer's dissatisfaction may be a reason for discontinuing further cooperation, or financial compensation up to the price of the training, after deduction of costs.

7. Copyright of the provided materials

7.1. The training materials provided by the trainer in the course of the training meet the characteristics of a copyrighted work in accordance with Czech Act No 121/2000 Coll.
7.2. None of the training materials or any part thereof may be further processed, reproduced, distributed or used for further presentations or training in any way without the prior written consent of the trainer.

8. Liability

8.1. The trainer does not assume responsibility for any shortcomings in the services of any third party that he uses in the training.
8.2. The trainer does not assume responsibility for injuries, damages and losses incurred by the participants in the training events or caused by the participants. Such costs, caused by the above circumstances, shall be borne exclusively by the participant in the training event.

9. Validity of the Terms

9.1 These General Terms and Conditions shall be valid and effective from 1 October 2024.