0

As far as I know, before sending and receiving data in HTTPS, there needs to be an SSL/TLS handshake. Is it reliable to consider every SSL/TLS handshake in port 443 as the start of an HTTPS connection?

For example, to understand how much data is transmitted between client and server via HTTPS, can you check for an SSL/TLS handshake in port 443 and then consider all session's packets as HTTPS.

2 Answers 2

5

There are a few things to unpack there, so I'll start with the following points:

  • Port 443 is usually used for encrypted HTTP (HTTPS) connections. It does not have to be. Web servers can be configured to listen for incoming connections on any port, HTTP messages will be transmitted and received just fine, and the TLS/SSL handshake will complete just fine. 443 is of course the standard though and used the majority of the time.
  • TLS/SSL is separate from HTTP. It just so happens it's really useful and widely used "on top of" HTTP. TLS/SSL is also used for video chats, messaging, secure FTP connections, etc. Simply, it's a method of securing communications. HTTP is just the most common type of communication secured.
  • Some of the details of the TLS handshake and how it's established a browsing session will use HTTPS instead of HTTP is explained will in this CloudFlare article and this Medium article. It all starts with the Client Hello message sent to the server. I've included an example of this message below, but it was originally hosted on GitHub.

Client Hello Message

 *** ClientHello, TLSv1.2
    RandomCookie: *** ClientHello, TLSv1.2
    RandomCookie: GMT: -1892413556 bytes = { GMT: -351008774 bytes = { 169, 131, 204, 213, 154, 96, 7, 136, 43, 142, 232, 138, 148, 171, 52, 226, 155, 202, 145, 57, 210, 132, 227, 182, 67, 222, 161, 28, 20 }
    Session ID: 239, 10, 92, 143, 185, {}
    93, Cipher Suites: [Unknown 0x8a:0x8a, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Unknown 0xcc:0xa9, Unknown 0xcc:0xa8, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
    ………………………………………………

Hope this helps!

1
  • So there is no way to detect if a packet is https or encrypted http after handshake process???
    – YosSaL
    Commented Dec 11, 2022 at 16:53
3

In addition to the answer from coderichardson: it is not only that https can be used at different ports than 443 but also that different protocols can be used at port 443 even though they start with a TLS handshake.

For example WebSocket over TLS (wss://) typically uses port 443 too, although one could argue that it is kind of HTTP since WebSockets are initiated by a HTTP handshake. But there are also application which deliberately mimic a TLS handshake in order to pass through firewalls. For example Skype did at least in the past some pseudo-ClientHello on port 443 in order to bypass DPI enabled firewalls which tried to restrict port 443 for HTTPS only. And of course one might simply tunnel arbitrary traffic (like a full VPN) through some TLS tunnel on port 443 if one controls both endpoints.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .