What is the difference between

http://serverfault.com:443 and https://serverfault.com:80

Which one is more secure theoretically?

  • 3
    HTTPS over port 80 may happen but only within server-to-server communication, browsers don't support that. The security is not about the port, it is about a protocol.
    – Anatoly
    Commented Jul 12, 2015 at 17:45
  • 6
    @Anatoly browsers support HTTPS over port 80, it is just that they don't default to it. The default port for HTTPS in browsers is 443, but you can override that in practically any browser. I think this is what you meant, but I wanted to clarify for anyone else. Commented Aug 12, 2016 at 15:05
  • @HurricaneDevelopment my comment was essentially what Nginx core engineers said over the Nginx forum at the time, not sure how things may have changed over time.
    – Anatoly
    Commented Aug 12, 2016 at 15:33
  • @Anatoly Fari enough, just adding some more info. Commented Aug 12, 2016 at 15:55

1 Answer 1


http and https refer to the protocol in use.

http is used for unencrypted cleartext communication, which means transferred data may be intercepted and read in plain by a human. Username/password fields may for instance be captured and read.

https refers to SSL/TLS encrypted communication. It must be decrypted to be read. Normally/ideally only the endpoints are capable of encrypting/decrypting the data, although this is a statement with caveats (see edit below).

Therefore https may be considered more secure than http.

:80 and :443 refer only to the server port in use (i.e. it is "just a number") and carries no significance at all with regards to security.

However, there is a strong convention to send http over port 80 and https over port 443, which makes the combinations in the question more than a little unorthodox. They are technically perfectly usable though, as long as the endpoints are in agreement and no intermediary filter objects.

So to answer, http://example.com:443 is less secure than https://example.com:80 and the difference is practical (even though it can be offset in a number of ways) and not merely theoretical.

You can easily test the validity of these statements using a webserver and client where you manipulate the serverport and the encryption status, whilst capturing and comparing each session with a protocol decoder such as wireshark.

[EDIT - caveats regarding the security of the client/server path]

What essentially amounts to an https man-in-the-middle attack can be performed for purposes of eavesdropping or impersonation. It may be done as an act of malevolence, benevolence or as it turns out even due to ignorance, depending on circumstance.

The attack can be done either through exploiting a protocol weakness such as the heartbleed bug or the Poodle vulnerability, or through instantiating an https proxy between the client and server in the network path or directly on the client.

Malevolent use does not need much explanation, I think. Benevolent use would be for example an organisation proxying incoming https connections for purposes of logging/ids, or outgoing https connections for filtering allowed/denied applications. An example of ignorant use would be the Lenovo Superfish example linked above or the recent Dell variation of the same slip-up.


Ever noticed how the world keeps the surprises coming? A scandal just erupted in Sweden, where three county council healthcare organisations have used the same supply chain for registering health care events through patient telephone calls.

As it were, the question thereby gets an answer on the grand scale of things. If only it were a practical joke and not an actual event...

I will simply paste two snippets translated from the news text in Computer Sweden:

”Computer Sweden can today reveal one of the greatest disasters ever regarding health care patient security and personal integrity. On an open webserver without any form of password protection or other method of security, we have found 2,7 million recorded calls from patients to the healthcare through the medical advisory number 1177. The calls go back to 2013 and contain 170.000 hours of sensitive voice call files which anybody could download and listen to.


The calls have been saved on Voice Integrated Nordics storage server at the ip address Tcp-port 443 indicates the traffic has been passed over https, but the session is not encrypted.

I cannot decide if this is yet another example of ignorance, or if we’re seeing an entirely new category. Please advice.

  • What did you mean by saying that statement about encrypting/decrypting the data has caveats? Please explain
    – Oleg
    Commented Dec 6, 2015 at 17:23
  • @Curious I have edited my answer to reflect on your question.
    – ErikE
    Commented Dec 6, 2015 at 18:35
  • 1
    Thank you @ErikE. A few days ago I noticed that most of https sites I visit (except for sites with EV SSL) are verified by avast! Web/Mail Shield Root (I use Avast antivirus), which made me a little confused. Now everything's clear, thanks to you
    – Oleg
    Commented Dec 6, 2015 at 19:22
  • 1
    possibly avast uses their own certs to decrypt ssl traffic. Depending on your security setup that might be an issue for you. See f.e. blog.avast.com/tag/man-in-the-middle Commented Dec 8, 2015 at 9:16

You must log in to answer this question.

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