What is HTTP? What is HTTPS? Should I use it?

[Dan Q]

Following some queries in the Shoutbox, this post attempts to simply describe the fundamentals and history of HTTP and HTTPS. Then, through that lens, tries to help you answer the question "should my website be available over HTTPS?" Ultimately, the choice is yours (sometimes), but I'll state up-front that I come down on the side of a soft "yes, use HTTPS", and I'll explain my reasoning.

(This'll be long. I'll spread it across a few posts to make linking easier!)

But first, let's play with some technology!

Let's talk HTTP

HTTP is a simple protocol. No, actually that's not true at all; what I mean to say is that in the simplest cases, HTTP is a simple protocol. Let's demonstrate that. We'll be using example.com, a simple website that's available over both HTTP (http://example.com) and HTTPS (https://example.com).

To really demonstrate the simplicity (with the caveats linked above) of HTTP, we're going to connect to this site without using a web browser! We're going to use a program called telnet, which comes standard with virtually every operating system (newer versions of Windows sometimes don't install it by default; go into Settings > Windows Features > Telnet Client to add it). Open up a terminal/command prompt, and type:

Code: plain

telnet example.com 80

Congratulations, you've connected to the website at example.com. The 80, by the way, tells your computer to connect to port 80 on example.com, which is the standard port for HTTP (it's so standard that you never see it: your web browser hides this from you every day - basically, putting 80 here indicates that you're connecting to a HTTP webserver, not an email server or a HTTPS webserver or a Gopherhole or a Gemini capsule, for example).

telnet will probably give you some indication of the fact; for example mine says to me:

Code: plain

Trying 23.215.0.136...
Connected to example.com.
Escape character is '^]'.

That's telling me (1) what IP address it used to connect to example.com, (2) that it successfully connected, and (3) that I can press CTRL and ] to stop talking to example.com and send commands to telnet itself if I want.

Now anything I type will be sent to the webserver at example.com. So I can type a "HTTP request" - what a web browser sends to a web server when it connects. Here's what I type:

Code: plain

GET / HTTP/1.1
Host: example.com

What did that mean? The "GET" means that I'm asking for something from the webserver. "GET" is the most-popular verb on the Web; you might also come across "POST" (which means "I'm sending you something"), but there are many others. The "/" is the web address I'm asking for, relative to the domain root: it's the bit that comes after the domain name in the address bar, up until any hash (#) character. HTTP/1.1 says what version of HTTP I'm using - HTTP/1.1 is pretty-much universally-supported.

"Host: example.com" says what domain name I was looking for: this is important because the webserver didn't get to see what we typed before we connected to it - it only knows that we connected to it's IP address. The "Host:" header was added as part of HTTP/1.1, and it's super useful because it means that more than one website can share the same IP address: absolutely essential to the modern Internet. (We'll be revisiting this in the history of HTTPS, where it posed an even bigger problem!).

I finish my request by pressing enter twice. This tells the webserver that I'm done making my request, and it's now it's turn to speak. It outputs a stack of headers and some HTML: that's the web page (and some metadata). Here's what the full thing looks like in my terminal right now:

Code: plain

$ telnet example.com 80
Trying 23.215.0.136...
Connected to example.com.
Escape character is '^]'.
GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "bc2473a18e003bdb249eba5ce893033f:1760028122.592274"
Last-Modified: Thu, 09 Oct 2025 16:42:02 GMT
Cache-Control: max-age=86000
Date: Wed, 03 Dec 2025 07:55:42 GMT
Content-Length: 513
Connection: keep-alive

<!doctype html><html lang="en"><head><title>Example Domain</title><meta name="viewport" content="width=device-width, initial-scale=1"><style>body{background:#eee;width:60vw;margin:15vh auto;font-family:system-ui,sans-serif}h1{font-size:1.5em}div{opacity:0.8}a:link,a:visited{color:#348}</style><body><div><h1>Example Domain</h1><p>This domain is for use in documentation examples without needing permission. Avoid use in operations.<p><a href="https://iana.org/domains/example">Learn more</a></div></body></html>

You can try this for yourself, and I'd encourage you to do so. You can also try playing around with it. E.g. instead of saying "GET / HTTP/1.1", try saying "I am a cabbage." and watch the webserver say that it didn't understand you. Or try connecting to example.com but change the "Host:" to "example.net": it'll still give you a web page, because example.com and example.net come from the same webserver; but change it to danq.me and it'll tell you that it can't help you with that.

[Dan Q]

So what's HTTPS?

Early in the Web's history, it became apparent that people might need to send data securely over the Web. (At least) two competing standards for this appeared, and the winner was HTTPS. The encryption part is basically the same as how PGP/GPG works, which I've talked about before, but the short of it is that the HTTP conversation (which we tried earlier!) gets wrapped in a protocol called SSL (more-recently TLS), which - as typically-used - provides a handful of cryptographic features that HTTP itself didn't have (which we'll look at in a moment!).

When I say it's "wrapped in SSL/TLS", you might enjoy an analogy. Suppose I've written a text file and I want to give it to you on a pendrive, but I'm worried the pendrive might be stolen? I might wrap the text file in a password-protected ZIP file. "Wrapping" in this context just means "re-encoding, with something different, in such a way that the original thing can be recovered from it later".

Anyway: HTTPS (as typically used) aims to provide the following features:

1. Privacy: nobody can see what we're talking about. When you did that telnet experiment earlier (and when you connect to any http:// website), that conversation is not private. Anybody on your network (especially if you're on WiFi), and your ISP, and your government, etc. can see exactly what website you connected to, exactly what web addresses you asked for, exactly what information you sent to those websites (e.g. login credentials, cookies), and exactly what those websites sent back to you. Privacy is the first thing people think about when they consider the features of HTTPS, and it's a big one... for some websites. Online shopping, banking, anything you can "log in" to, etc. should certainly use HTTPS. Anything else where you might not want other people on the same public WiFi to see what you're up to comes a close second (search engines, dating sites, medical information sites... the list goes on!).

Caveat: under normal circumstances, the people on your LAN, your ISP, your employer, your school, your government or whomever can potentially still see which websites you connect to, just not what pages you request, what's on those pages, or what you fill in on them. Spies call this "metadata", and it's actually quite compelling: if I know that you routinely visit Fetlife from your work computer, it might not matter that your employer doesn't know which account is yours: the fact that you're frequenting a site about sexual fetishes alone might be enough to get you fired.

2. Integrity: nobody can modify what we say to one another. A side-effect of encryption is not only that our fellow LAN users, ISP, employer, government etc. can't see what we send to webservers and what's on the pages that come back, they can't change them either. This is more-important than you might think: if I could "inject" my own HTML code into the pages your bank sent you, it wouldn't matter that they use two-factor authentication because I can just have the page say that it's failed and you need to phone us to get it fixed (and give a phone number that's actually mine!). But it's not just high-security applications like banking that benefit from integrity: there are plenty of examples of times where dodgy ISPs have injected advertisements onto http:// webpages, or where oppressive governments have inserted keylogging or other "tracking" code. Using https:// helps to fight against censorship and oppression!

Caveat: weeeelll... oppressive regimes (and even unscrupulous employers and well-meaning schools) can get around both of the above benefits by exploiting either (a) flaws in the below feature, or (b) more often, the fact that they control the hardware: if you can't trust the computer you're using, you can't be sure if it's bypassing any or all of the security benefits of HTTPS. So be aware if you're using e.g. a locked-down computer from your employer where you can't edit the settings for yourself... that those settings might be configured in a way that undermines the privacy and/or integrity of the websites you visit. Of course, this applies to everything else you do on an untrustworthy computer too, not just the Web!

3. Identity: the third pillar of HTTP's features is one of the most-powerful... but also one of the most-controversial. When you connect to paypal.com, how can you know that you're actually connecting to paypal.com and it's not that your connection is being intercepted and rerouted to some rogue site (e.g. by malware running on your router, by a hacker on the same public wifi, or by your ISP or government)? Anybody can make a HTTPS "certificate" (encryption keypair) that says whatever they like (it's really easy!): so how does your browser know that this one that says "paypal.com" is legit? Well: certificates can be "signed" by another certificate. So if the "paypal.com" certificate is signed by the holder of a different certificate, and you trust that other certificate, then the site must be legit, right?

The smart among you are probably already one step ahead and asking "well how does my computer know it can trust that other certificate?", and that's were it gets controversial. Your operating system (or browser) comes pre-installed with a list of approved "Certificate Authorities". Here's part of mine, from Firefox:

You can modify the list, which can be very useful if you want to give new life to an old device. E.g. @xwindows mentioned how the (necessary) rollover of some root certificates stopped some older mobile devices accessing a lot of websites, because those mobile devices weren't receiving updates any more. Well: the owners of those mobile devices could have kept them going just by manually installing the new root certificates for themselves! But nobody was willing to educate them or help them, so sadly most people just threw those old devices away. It's also useful if you've got good reason not to trust a particular certificate authority: for example there've been times in the past where oppressive regimes with totalitarian control have used their power to force companies in the approved Certificate Authorities list to sign fake certificates so that they can more-easily spy on their citizens. Incidentally: it's in this list that you'll find any "fake" Certificate Authority installed by your school or employer if they want to be able to spy on all your https:// traffic - there's an (obvious) fake one on my computer (that I added): can you find it in the screenshot?

"Who gets to be in the approved Certificate Authority list (for any given operating system or browser)?" is only one of the controversies in HTTPS's identity system (fun fact: some competing protocols like Gemini dispense with an identity step entirely, which trades one set of problems for a different set). The other big one was that the Certificate Authorities - especially when there were relatively few of them - had a virtual monopoly on the sale of "signatures" for your certificates. Anybody can make a certificate, but browsers will put up (increasingly) scary security warnings if those certificates aren't signed by a trusted Certificate Authority, and so for many years the big Certificate Authorities would absolutely gouge prices. There were some solid efforts by open source/transparency advocates to challenge the monopolies (my personal favourite was, and remains, CACert, but they've kinda lost the race now), but the victory came with Let's Encrypt, who started providing easy, quick, domain-verified certificate signing for free, to anybody. Nowadays more HTTPS websites use Let's Encrypt than anybody else, and it's allowed free/cheap HTTPS to be rolled out to the masses. If you're on NeoCities, you're using Let's Encrypt. Melonland uses Let's Encrypt. I use Let's Encrypt. Basically everybody who doesn't have a real reason to use somebody else for their HTTPS certificate... uses Let's Encrypt. It's a victory for the open web.

If you're following along with the technical examples: you can't use telnet to connect to a HTTPS website (well, you can, but only if you can encrypt and decrypt 256-bit ciphers in your head [protip: you can't]), but if you've got openssl installed, you can use that. You'd need to run something like:

Code: plain

openssl s_client -connect example.com:443

(443 is the port typically used for HTTPS, just like 80 is the port typically used for HTTP; these "magic numbers" are just agreed on by everybody!)

Want to see it in action? You asked for it! Here's me doing the same thing as I did earlier - connecting to example.com and asking for the root web page, from my terminal... but this time I'm doing it over HTTPS. The bits I send to the server are exactly the same, but I see a lot more output:

Code: plain

$ openssl s_client -connect example.com:443
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G3
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1
verify return:1
depth=0 C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, CN = *.example.com
verify return:1
---
Certificate chain
 0 s:C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, CN = *.example.com
   i:C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Jan 15 00:00:00 2025 GMT; NotAfter: Jan 15 23:59:59 2026 GMT
 1 s:C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G3
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Apr 14 00:00:00 2021 GMT; NotAfter: Apr 13 23:59:59 2031 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFmzCCBSGgAwIBAgIQCtiTuvposLf7ekBPBuyvmjAKBggqhkjOPQQDAzBZMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMTMwMQYDVQQDEypEaWdp
Q2VydCBHbG9iYWwgRzMgVExTIEVDQyBTSEEzODQgMjAyMCBDQTEwHhcNMjUwMTE1
MDAwMDAwWhcNMjYwMTE1MjM1OTU5WjCBjjELMAkGA1UEBhMCVVMxEzARBgNVBAgT
CkNhbGlmb3JuaWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRl
cm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMx
FjAUBgNVBAMMDSouZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AASaSJeELWFsCMlqFKDIOIDmAMCH+plXDhsA4tiHklfnCPs8XrDThCg3wSQRjtMg
cXS9k49OCQPOAjuw5GZzz6/uo4IDkzCCA48wHwYDVR0jBBgwFoAUiiPrnmvX+Tdd
+W0hOXaaoWfeEKgwHQYDVR0OBBYEFPDBajIN7NrH6o/NDW0ZElnRvnLtMCUGA1Ud
EQQeMByCDSouZXhhbXBsZS5jb22CC2V4YW1wbGUuY29tMD4GA1UdIAQ3MDUwMwYG
Z4EMAQICMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NQ
UzAOBgNVHQ8BAf8EBAMCA4gwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC
MIGfBgNVHR8EgZcwgZQwSKBGoESGQmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydEdsb2JhbEczVExTRUNDU0hBMzg0MjAyMENBMS0yLmNybDBIoEagRIZC
aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0R2xvYmFsRzNUTFNFQ0NT
SEEzODQyMDIwQ0ExLTIuY3JsMIGHBggrBgEFBQcBAQR7MHkwJAYIKwYBBQUHMAGG
GGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBRBggrBgEFBQcwAoZFaHR0cDovL2Nh
Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0R2xvYmFsRzNUTFNFQ0NTSEEzODQy
MDIwQ0ExLTIuY3J0MAwGA1UdEwEB/wQCMAAwggF7BgorBgEEAdZ5AgQCBIIBawSC
AWcBZQB0AA5XlLzzrqk+MxssmQez95Dfm8I9cTIl3SGpJaxhxU4hAAABlGd6v8cA
AAQDAEUwQwIfJBcPWkx80ik7uLYW6OGvNYvJ4NmOR2RXc9uviFPH6QIgUtuuUenH
IT5UNWJffBBRq31tUGi7ZDTSrrM0f4z1Va4AdQBkEcRspBLsp4kcogIuALyrTygH
1B41J6vq/tUDyX3N8AAAAZRnesAFAAAEAwBGMEQCIHCu6NgHhV1Qvif/G7BHq7ci
MGH8jdch/xy4LzrYlesXAiByMFMvDhGg4sYm1MsrDGVedcwpE4eN0RuZcFGmWxwJ
cgB2AEmcm2neHXzs/DbezYdkprhbrwqHgBnRVVL76esp3fjDAAABlGd6wBkAAAQD
AEcwRQIgaFh67yEQ2lwgm3X16n2iWjEQFII2b2fpONtBVibZVWwCIQD5psqjXDYs
IEb1hyh0S8bBN3O4u2sA9zisKIlYjZg8wjAKBggqhkjOPQQDAwNoADBlAjEA+aaC
RlPbb+VY+u4avPyaG7fvUDJqN8KwlrXD4XptT7QL+D03+BA/FUEo3dD1iz37AjBk
Y3jhsuLAW7pWsDbtX/Qwxp6kNsK4jh1/RjvV/260sxQwM/GM7t0+T0uP2L+Y12U=
-----END CERTIFICATE-----
subject=C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, CN = *.example.com
issuer=C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2722 bytes and written 393 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 6D9B100FE763B750D473B51D25DAFCDD98F07946EE2F0E0CDBDD65BE88D51258
    Session-ID-ctx:
    Resumption PSK: 60058302A04018DABA199AADD4A2A16F1D8A3F9DB0B7B8CC032787F98B79F3C052C5A06E94857687CEBAC6220E9BED41
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 83100 (seconds)
    TLS session ticket:
    0000 - 00 02 0d ff 82 f3 22 d4-12 c4 94 fc 34 62 e9 cc   ......".....4b..
    0010 - 50 d6 c4 9d d1 06 e8 56-ae 56 6a b7 63 06 b3 93   P......V.Vj.c...
    0020 - 6e 30 91 f4 83 ba b7 3a-3a f3 cd 78 8f b9 ec b1   n0.....::..x....
    0030 - c9 85 dc 47 19 15 c4 e1-74 76 ec 69 c1 d3 2b 4c   ...G....tv.i..+L
    0040 - 03 63 cf 51 e6 7d ef 0a-06 52 63 cf 0f b9 5a 4d   .c.Q.}...Rc...ZM
    0050 - a7 8b 1e 45 ac cf 8d 39-fd 94 0f ed 75 0c 0a a5   ...E...9....u...
    0060 - 77 b2 db 44 01 8a e2 b3-92 db 47 bd 0c 56 c4 a4   w..D......G..V..
    0070 - 58 44 ee 47 88 0d fc bb-aa 2f ac 82 04 8c 1b ae   XD.G...../......
    0080 - cd 4b be d1 8b 8e 30 ff-9a e1 75 88 e6 e8 9a 7f   .K....0...u.....
    0090 - e5 2e 2d b4 b3 3d d8 05-0d 09 7e 2b ba f5 af 5a   ..-..=....~+...Z
    00a0 - 5e 5c a9 7e 61 ef 0d f7-83 27 8e 01 c9 6b 62 5b   ^\.~a....'...kb[
    00b0 - 41 42 41 1e 40 08 3e a1-01 1c ce 91 3f 1f e8 f3   ABA.@.>.....?...
    00c0 - fa 62 88 5d 46 2d 85 14-4b 2e 1d 77 7c 86 66 42   .b.]F-..K..w|.fB
    00d0 - 02 ed 17 a2 3e ec 1b 5d-49 58 d8 d7 95 be 10 c6   ....>..]IX......
    00e0 - 83 64 d1 e9 d7 44 ed 3a-f2 bf d6 6d 0d b9 a2 3d   .d...D.:...m...=

    Start Time: 1764754085
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 6895976A30FB37F888EFD333B65B6E25EDAACB61A70178D3AD389BB572C49ADE
    Session-ID-ctx:
    Resumption PSK: 6FE45EAC0BEED235DE1749725148F441FCC92D107C9099B490237F0E0836E07DA843057C28997B3F84A27F156457122F
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 83100 (seconds)
    TLS session ticket:
    0000 - 00 02 0d ff 82 f3 22 d4-12 c4 94 fc 34 62 e9 cc   ......".....4b..
    0010 - 09 83 83 6b fc 6c d4 09-86 d9 d5 9e ed ac 2c 97   ...k.l........,.
    0020 - 67 5b 6c 6c 6f f1 a3 b7-22 be 60 d0 69 1d 6c 26   g[llo...".`.i.l&
    0030 - b1 6c e6 40 39 fc 88 00-d8 7b fa 81 8d 49 fc 3f   .l.....{...I.?
    0040 - d3 64 e1 24 ae 4b 04 36-bf be 28 e6 88 98 81 96   .d.$.K.6..(.....
    0050 - 02 98 49 bb f3 09 7a 08-48 c2 3c d8 57 2d 1f 5b   ..I...z.H.<.W-.[
    0060 - 6c 9d 02 6d 91 00 fe 10-ae c7 ac aa c5 2a ef f0   l..m.........*..
    0070 - 62 38 50 d7 37 b2 dc 6e-08 26 38 d2 9a ec 52 21   b8P.7..n.&8...R!
    0080 - 4c 54 9f 9a 87 14 00 ad-5b e1 ad 9f bf 71 21 cd   LT......[....q!.
    0090 - dc 9c 17 04 df 89 5c 79-7b b8 b6 57 9d 60 9a 48   ......\y{..W.`.H
    00a0 - 24 8b 32 4a 37 28 d4 2f-3b 73 a8 cf dd c7 65 89   $.2J7(./;s....e.
    00b0 - 4c e9 b7 5f 39 90 62 73-83 99 c5 9b db b4 fb f9   L.._9.bs........
    00c0 - c1 13 9f d6 9a 64 bc 82-20 a5 25 d0 44 b4 65 3e   .....d.. .%.D.e>
    00d0 - 39 c7 28 c7 93 60 c0 ae-db bf 26 cb 03 d0 1a 8e   9.(..`....&.....
    00e0 - 59 03 58 bb 47 08 3d 7c-b1 0f 8e f8 1b 33 12 c7   Y.X.G.=|.....3..

    Start Time: 1764754085
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "bc2473a18e003bdb249eba5ce893033f:1760028122.592274"
Last-Modified: Thu, 09 Oct 2025 16:42:02 GMT
Cache-Control: max-age=86000
Date: Wed, 03 Dec 2025 09:28:11 GMT
Content-Length: 513
Connection: keep-alive
Alt-Svc: h3=":443"; ma=93600

<!doctype html><html lang="en"><head><title>Example Domain</title><meta name="viewport" content="width=device-width, initial-scale=1"><style>body{background:#eee;width:60vw;margin:15vh auto;font-family:system-ui,sans-serif}h1{font-size:1.5em}div{opacity:0.8}a:link,a:visited{color:#348}</style><body><div><h1>Example Domain</h1><p>This domain is for use in documentation examples without needing permission. Avoid use in operations.<p><a href="https://iana.org/domains/example">Learn more</a></div></body></html>

The extra (huge) bit of text there is openssl telling me what certificate was presented by example.com, what encryption mechanism was agreed upon by my computer and theirs, and so on... but then I just type GET / HTTP/1.1 and Host: example.com as normal, and I get a web page back as normal (scroll to the bottom of the code block to see the familiar bit!).

It's still plain old HTTP/1.1, just wrapped up in a layer of encryption.

[Dan Q]

Extra features of HTTPS

If it really were just a case of "HTTPS is HTTP, but with Privacy, Integrity, and Identity built-in", then I'd 100% agree that HTTPS wasn't necessary for most sites. And it's not "free": connecting to a HTTPS site uses (a tiny bit) more processing power (and therefore more electricity!) than a plain old HTTP website, to do the heavy lifting of that cryptography (although modern processors tend to have features to make that cryptography much more-efficient).

But, for good or evil, HTTPS has more features. There are a few reasons for this. A benign reason is that the nature of HTTPS means that it's easier to add certain advanced features to it. A less-benign one is that certain monopolies (cough... GOOGLE!) have used their position of power to strongarm the development of the Web such that some new features are arbitrarily only available over HTTPS. But whatever the reason (and as I indicate: they vary, and some of them are totally legit), HTTPS does provide features that HTTP does not. These include:

• HTTP/2 and HTTP/3, the latest versions of HTTP, which provide better performance (especially on websites with lots of dependencies, e.g. many separate JS files or images), are only available over HTTPS
• New JavaScript APIs like Geolocation, Bluetooth, and Notifications are only available over HTTPS in most browsers (and there's talk of features like the Fullscreen API becoming this way)
• Service Workers, which can be used to make a website e.g. "work offline", are only available for websites served over HTTPS
• Users will see warnings on non-HTTPS sites, e.g. the words "Not secure" in the address bar, or warnings on password fields
• Increasingly, some users are configuring their browsers to only visit HTTPS sites (or using plugins that do the same) and not HTTP sites
• Some search engines discriminate against non-HTTPS sites, which is f$£@ing sickening in my mind but that's the world we live in - anyway, they end up drifting down the search results pages, if that's the kind of thing you care about
• Some new gTLDs require HTTPS: if your domain name ends .app, .bank, .boo, .dad, .day, .dev, .eat, .fly, .ing, .meet, .meme, .new, .rsvp, .zip, or one of many dozens of others... then your domain is already on the "HSTS Preload List" pre-compiled into most browsers... this basically means that most browsers will refuse to even try to connect to them over plain HTTP and will always jump straight to HTTPS (it's also possible to add your own domain to this list: mine - danq.me - is, for example)

[Dan Q]

So... should I use HTTPS for my website?

It's up to you. Assuming you have control over such things (which depends on your host) are basically four options:

1. Only HTTP, reject HTTPS. You'll miss out on some of the shiny new features which are only available over HTTPS, but your site will be available to browsers going all the way back to the mid-to-late 1990s when HTTP/1.1 got widespread adoption. And it's easy to set up. A fine choice, if you understand what you're missing out on.

2. Only HTTPS, reject HTTP. Not recommended unless your domain is in the HSTS Preload List, and even then it's a bad choice for backwards compatibility. Doesn't work at all for users on very old browsers/operating systems, whose browsers don't speak HTTPS (or don't speak "modern" HTTPS).

3. Both HTTP and HTTPS. Let your users choose which they want, and optionally try to detect and auto-upgrade users to HTTPS if they support it. Just be careful that if you're doing authentication that any cookies are set with the Secure flag so they don't "leak" over HTTP, and be aware that you won't be able to rely on HTTPS-only features. A fine choice if that's your jam.

4. HTTP redirecting to HTTPS. Like HTTPS-only, but with HTTP connections being automatically redirected to HTTPS. Helps people whose browsers don't use the HSTS Preload List, or if your site's not in the list. Doesn't work for users on very old browsers/operating systems, of course, whose browsers won't be able to follow the redirect.


Wow, that was a lot. Any questions?