5

If I am running a web server on port 80 and I also have port 443 (HTTPS) turned on but it is not enforced. I did not self-sign or sign with a proper CA (i.e., I don't use SSL for my site), does leaving port 443 turned on pose a threat to my web server? For example, could an attacker hack port 443 and come into my website at port 80?

  • 3
    What do you see as the added value of using port 443 versus only port 80? – pr- Oct 28 '15 at 13:17
  • 1
    I could see some value in being able to respond on https:// and redirect it to http:// without a server error, but that won't happen just by leaving 443 open (unless I'm much mistaken) - you'll have to have a proper SSL certificate for even that to work, and if it's self signed your users are still going to get the warning about an untrusted certificate. – Jason Oct 28 '15 at 14:16
  • If you want a proper SSL certificate for free, just to allow the https:// protocol to work, this was the first result on Google - I make no guarantees as to their reliability or trustworthiness, but it's the only one I saw (in 3 minutes of searching) that was free for a full year cert that is renewable. – Jason Oct 28 '15 at 14:21
  • 1
    Please define what you mean by "turned on". – schroeder Oct 28 '15 at 14:56
  • I'm not sure I understand. Are you running https or not? In one sentence you say you're using https, in the next you say you're not using SSL. Which is it? https is http over SSL. You can't run https without using SSL. – Steve Sether Oct 28 '15 at 17:45
12

So you're running port 443 on a web server using plain HTTP (no TLS/SSL)?

Best practise is to close any ports that are not being used.

It depends on where the web root for port 443 is configured to look on your server. If this is the same location as your normal website then this could be a risk if there are certain items that need to be secured via configuration that is missing on this second webroot's setup.

If it is configured to look elsewhere, then files could be unintentionally exposed.

It is not a security risk to your users because they will not see https:// or the padlock in the browser address bar. They would simply see http://example.com:443/ which gives the same security as port 80 would (http://example.com/).

3

Running the port 443 the way you described can be troublesome because the data that transits through it will be encrypted but there is no way for a peer to be sure that it is communicating with you and not with someone else (man-in-the-middle attacks) the server will attempt to transmit in the clear while almost any conventional client will be expected encrypted traffic and (hopefully) abort with a 'failed SSL handshake' error.

Would attacker hack port 443 and come in to my website at port 80?

You have to worry about all open ports as I commented below. Do not open a port you do not need.

You may be interested to read this: Using SSL-port (443) for non-SSL traffic, bad idea?

  • 1
    Hi thanks for reply. However, my actual site is still on port 80. Do I need to care what's coming from port 443? – Pang Ser Lark Oct 28 '15 at 7:45
  • 3
    By principle you have to worry about all open ports. @PangSerLark – user45139 Oct 28 '15 at 7:51
  • 2
    Just remember to consider your server too, not just your website. – Arlix Oct 28 '15 at 8:38
  • 4
    It won't be encrypted - the OP said without using SSL (from which I assume they mean without TLS/SSL). – SilverlightFox Oct 28 '15 at 10:16
  • @SilverlightFox You are right: I guess he reworded the question after I answered, so I am not going to write what you have written below. May be yours and mine are the full answer :) +1 anyway. – user45139 Oct 28 '15 at 10:20
2

You can run HTTP on any port (and similarly HTTPS on any port). Conventionally, you run HTTP on port 80, HTTPS on port 443, as using these well defined ports lets users not specify the port number.

If you connect to https://example.com it will make a HTTPS request to port 443. If you are try connecting to a port not running SSL/TLS with the HTTPS protocol you'll get a SSL connection error. You can see this for example, if you try connecting to to https://security.stackexchange.com:80. This is what will happen if you run HTTP on port 443 at example.com; any user connecting to https://example.com will get that error.

Conversely if you try connecting to a port running HTTPS with your browser making the request via the regular old HTTP protocol, you'll get a 400 Bad Request HTTP error message (The plain HTTP request was sent to HTTPS port). You can see an example of this error by going to: http://www.time.com:443/. Please note that HSTS slightly complicates things; if you are running HSTS, your browser may automatically switch HTTP requests to HTTPS ones for a given site. (This is why you will not see this error if you try going to http://www.facebook.com:443/ and would be redirected to https://www.facebook.com).

If you want https://example.com requests to work, but do not need the security of SSL, you should get a properly signed certificate. This can be done for free with https://letsencrypt.org/ and there are many other low cost solutions. If you really do not want users using HTTPS, you can then have rewrite rules redirect from HTTPS to HTTP. (Please note to use these redirects without browser warnings about an invalid SSL certificate, you need a valid SSL certificate).

EDIT: Removed recommendation for StartSSL as it is no longer trusted by major browsers.

0

Beside the security aspect you will be breaking standards. If you start a HTTP server on port 443 and access it via a normal browser, you get

gibberish on the server side:

# python -m http.server 443
Serving HTTP on 0.0.0.0 port 443 ...
127.0.0.1 - - [28/Oct/2015 17:33:53] code 400, message Bad request version ('À+À/\x00\x9eÌ\x14Ì\x13Ì\x15À')
127.0.0.1 - - [28/Oct/2015 17:33:53] "▬♥☺ Ì☺  È♥♥◄mûú£ô↑ß\x99\x9e´q¨è÷ü¿c↔↓<2)ÂTO\x8f^¤:2→   À+À/ \x9e̶Ì‼̧À" 400 -
127.0.0.1 - - [28/Oct/2015 17:34:03] code 400, message Bad request version ('\x8er*Êå¦\x10xÆE\x05úH6X+\x00\x00\x14À')
127.0.0.1 - - [28/Oct/2015 17:34:03] "▬♥☺ \x9d☺  \x99♥☻ü▲Eÿµp=\x9b¹?kàê½↕▲\x8er*Êå¦►xÆE♣úH6X+  ¶À" 400 -
127.0.0.1 - - [28/Oct/2015 17:34:13] code 400, message Bad HTTP/0.9 request type ('\x16\x03\x01\x00\x9d\x01\x00\x00\x99\x03\x01Q¤')
127.0.0.1 - - [28/Oct/2015 17:34:13] "▬♥☺ \x9d☺  \x99♥☺Q¤↔:BÀ/o{XÈ\x8d↑|ÈÖÂ\x91á\x8c↕£ÿdá◄è¹\x8e"}÷  ¶À" 400 -

and protocol errors on the browser side

enter image description here

  • I'm not sure the OP means he is running a web server on that port – schroeder Oct 28 '15 at 16:56
  • 1
    @schroeder: I am not sure either, this i snot clear form the question (and the answers BTW). Your comment about defining 'open' under the question is relevant. – WoJ Oct 28 '15 at 17:00
  • This is not strictly true that you're breaking a standard. https will default to port 443. But using port 443 doesn't imply you're running https on it. In your example you get errors because the URL you're using has https instead of http. Had you used http://localhost:443, everything would work perfectly fine. No standard is broken. – Steve Sether Nov 20 '15 at 14:30
  • @SteveSether: it depends on the semantics of "standards". In TCP/IP the port is disconnected from the service (anything can run anywhere) and this is used in many cases (I run some SSH servers on 443 and 9856, for various reasons). By mentioning "standards" I rather had "what is expected" more than "RFC". In the case of the OP, he obviously has problems with concepts like "open ports" (I also have port 443 (HTTPS) turned on but it is not enforced) so it is best to start with a setup in line with everyone's expectations (including the browser) and go from there with the troubleshooting. – WoJ Nov 20 '15 at 14:38
  • @Woj Then the word you're looking for is conventions, not standards. I'd say most people would say standards means a published standard, like an RFC. There's also de-facto standards (often unpublished), like the Microsoft .doc format. But what you're talking about is a convention or a social norm. People might look at you a little funny for putting http on port 443, but you're not going to break any software by doing so. – Steve Sether Nov 20 '15 at 14:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.