SSL/TLS ClientHello Analyzer

Analyze ClientHello messages and TLS negotiation parameters

Analyzing ClientHello...

ClientHello Analysis

TLS Version

Cipher Suites

ALPN

Extensions

Supported Groups

About Client Hello Analyzer

Analyzes TLS Client Hello messages to identify supported cipher suites, extensions, and protocol versions. Reveals client-side TLS capabilities and preferences.

How to Use

1Enter your domain name and optional port number
2Click "Analyze ClientHello" to capture the message
3Review cipher suites, extensions, and supported groups

Use Cases

•Debug TLS handshake failures
•Verify client compatibility with server
•Security auditing of client TLS capabilities

Frequently Asked Questions

A Client Hello is the first message sent by a client during a TLS handshake. It contains the client's supported TLS versions, cipher suites, extensions, and other negotiation parameters.

Analyzing Client Hello helps identify why a handshake might fail, verify client capabilities, and ensure compatibility between clients and servers. It's essential for debugging TLS issues.

If a client doesn't support your server's cipher suites, update either the client or server configuration. Use the SSL Hardening Config Generator to create compatible configurations.

Supported groups and signature algorithms, far more often than cipher suites. Both lists were extended as algorithms were deprecated, and servers were updated at different times, so a handshake fails when the intersection between them is empty even though the cipher lists overlap perfectly. A second common cause is SNI: without the server name extension the server cannot choose the right virtual host and returns a certificate for the wrong site. Check those two before suspecting ciphers.

Up to TLS 1.2 it can, because the server is choosing from a list the client ordered by preference. With TLS 1.3 it does not: the suites are not negotiable in the old sense and each is safe, so the client picks from a much smaller set. Server preference is also only advisory in 1.3. This is worth knowing when reading a result, because a strong suite appearing first in the offer tells you less about 1.3 than it does about 1.2.

Because without SNI the server hosting many sites on one address has no way to know which certificate to return, and would serve its default. The name is sent in the clear during the handshake, which is a known limitation of TLS rather than a flaw in SNI, and it is one of the reasons more recent protocols carry encrypted client hello. For any site behind shared hosting it is not optional, and its absence is a reliable explanation for a certificate mismatch.

By what each one adds rather than by its name. SNI carries the hostname, ALPN negotiates the application protocol, status_request asks for a stapled revocation response, session_ticket and pre_shared_key enable resumption, and supported_versions declares TLS 1.3. An extension the server never receives cannot be used, so its absence from the client's list explains a feature that silently does not work — OCSP stapling is the usual example, and it costs the client a round trip to a third party that nobody notices until a page feels slow.

Yes, and that is generally the more valuable direction. Rather than testing your own browser, which will almost always succeed, send a Client Hello shaped like the client you suspect and see whether the handshake completes. That reproduces the failure without needing the device, and the difference between what that client offers and what your server accepts is usually visible in one line of the result.

How the Analysis Works

The Client Hello is the first message a client sends, and it tells the server everything about what it can do. That makes it the single most useful place to look when a connection fails, because whatever is missing from this message is what the server had to fall back to.

1Offer the protocol versions and cipher suites the client supports, in the order it prefers them. The server picks from this list and nowhere else, so what is absent cannot be negotiated.
2Declare supported groups for key exchange. A client offering only groups the server also supports forces a fallback that is usually weaker, and a mismatch here is a common cause of a handshake that fails outright.
3Declare supported signature algorithms. This is where certificate compatibility is decided: if a client's algorithm list does not intersect the server's certificate, the connection fails no matter how well the ciphers match.
4Add the extensions that carry hostname, protocol negotiation, revocation status and session resumption.
5Complete the handshake and record what was selected, so the offer and the outcome can be compared side by side.

The useful output is the gap between the two. A downgrade that only appears in the negotiated result means the server declined something the client offered and you have narrowed the fault to the server; a client that never offered it means the fault is on the client.

Tips & Best Practices

•Analyze ClientHello messages to understand client TLS capabilities
•Use ClientHello analysis to diagnose compatibility issues
•Compare ClientHello messages from different browsers and tools
•Monitor ClientHello patterns for security analysis

Technical Details

Message: TLS ClientHello message structure and content analysis
Fields: Suggested version, cipher suites, extensions, curves
Fingerprint: JA3 fingerprint generation from ClientHello
Output: ClientHello analysis with supported features