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?

[Dan Q]

There was some discussion on an unrelated thread about the value of HTTPS, and I wanted to pick up on some of @Rubbereon's points:

First, in response to @schlime9k:

HTTPS is not far more secure than HTTP, all it does is it encrypts your connexion.

A bit of an oversimplification, even where it's nominally true. Let's say for a moment that "all" HTTPS does is encrypts your connection. What does that actually mean? Well, it means that an attacker (by "attacker", I in practice mean "anybody on the same LAN as you": if you use the free WiFi in a cafe or library, I mean anybody else in that cafe or library, for example) cannot:

1. redirect your request to their own server; they can in some circumstances block it, but they can't spoof it
2. see what web pages you requested, what you typed into any forms (this is why it's particularly important for login forms etc.)
3. (in some versions of HTTPS) see what domain name you requested, what browser you're using, your cookies, etc.
4. modify your request so that e.g. it looks like you requested a page that you didn't or that you filled in a form differently than you did
5. inject response headers to e.g. set cookies on behalf of the website you're visiting (which they can then also use to track you)
6. modify the content of the web page you receive, e.g. to inject malware, cryptominers, ads, or other defacement

That's quite a lot of benefits from "just" encryption!

But "encryption" isn't the only thing that HTTPS provides. Like all split-key cryptographic systems, it provides two additional benefits that aren't often talked about (these are benefits that other TLS-based protocols, like Gemini, don't have [and that's fine, because encryption alone is pretty damn good!]):

1. Non-repudiation: if you log your traffic, a HTTPS connection log proves that a webserver sent a particular message. Because only the certificate stored on the server could possibly have been used to produce the signature that's attached to the key exchange.
2. Identity verification: so long as you trust the certificate authority (and if you don't, you should remove them from your trusted CA list shouldn't you!), you can be assured that the website is "who it says it is". For the simplest certificates, "domain verified" ones like you get for free from Lets Encrypt, this proves that you really were talking to e.g. forum.melonland.net, because the certificate issuer checked that the person they signed the certificate for proved that they controlled that domain name at the time of its issue.

And that's just the common things HTTPS provides. Did you know that it can also:

1. Verify the identity of the user. It never really took off in the way it ought to have, but it still works (I use it every day!) - you can have a certificate in your browser too and it can prove who you are to the server. It's much more-secure and less-inconvenient than usernames and passwords, for most people, most of the time. (It's a real shame it never caught on; passkeys/webauthn are kinda-sorta the same thing, but they're not protocol-level and need JS which is a drag!)
2. Ensure that HTTPS is used on future visits: a big issue with HTTP and HTTPS's coexistence is that most people don't type the https:// when they enter a domain name, and many browsers will try the http:// one (at which point at attacker could pounce!) first. But thanks to technologies like HSTS, a browser can remember (or even be pre-compiled with knowledge) that a particular domain name should always be accessed over HTTPS, plugging that loophole (and improving performance, to boot!).

So you see, it's a lot bigger than "just" encryption!

Anyway:

a SSL certificate only matters on web 2.0 and above (web 3.0 with the fediverse and the blockchain and that's it unless they make more of these).

"Web 2.0" and "Web 3.0" are marketing terminology, not standards. Ask three people what they mean and you'll get four different answers, and none of them are necessarily "wrong".

SSL/TLS was and is absolutely essential for "Web 1.0", however you choose to define it, too. Amazon and eBay were both processing financial transactions online long before anybody ever said "Web 2.0".

If somebody, let's say Joe, runs a static web 1.0 website then the cerificate is useless because what are bad actors gonna do about it?

You could say, "but then they use javascri-" BUT browsers are so secure by design that anything more than a spyware tracker is not gonna work.

The big attack vector right now is cryptominers. If an attacker can inject JavaScript/WASM that mines Bitcoin, they can burn your battery and clock cycles to make themselves money.

Other attacks work by injecting code that opens a popup to another site which attempts to install a service worker. That way, the attacker can use your spare processing power to help make themselves rich at the expense of your computer's performance (and the planet in general) even after you're done visiting the site.

Another attack vector is to inject an overlay that, when clicked (to trigger interaction) opens a different spoofed website in the hope that you'll later forget why you were there. E.g. you visit Joe's site and start clicking around, and then find a website open in another tab that looks like PayPal. Were you in the middle of logging in to PayPal? You put your credentials in and... oh, that was a fake site, opened by the attacker using an attack vector on Joe's site.

A particularly insidious variant of that, sometimes used on free hotel wifi (by somebody staying in any other room and on the same wifi network), is to inject code that shows a popup to say that you've used your allowance of free hotel wifi and you need to pay some small sum to continue unlimited browsing. But that form's not from the hotel, it's from the attacker, who's now got your credit card number (or personal details, if it just asks for e.g. room number and name).

These are all documented real attacks that have taken place against victims who tried to access arbitrary http sites. They're not common, but they are real, and by choosing to not make your site https:// you might be choosing to make it easier for attackers to target your visitors.

Certificates can cause untold amounts of problems

They've gotten pretty easy nowadays, thanks mostly to the likes of Lets Encrypt. Plus: the ramping-up curve on most TLDs (unless e.g. you bought a .dev, which are 100% HSTS-preloaded) is gentle: you can run HTTP and HTTPS side-by-side for as long as you like; you can change your mind and roll back from HTTPS to HTTP, etc. It's not much harder, nowadays, than selfhosting any website.

In fact, if you use my favourite webserver Caddy then it's easier to use HTTPS than HTTP! Caddy makes it so easy to run a site securely. Here's the Caddy configuration for a HTTPS site called example.com (with HTTP-to-HTTPS redirection); a static site with files in the /var/www/example.com directory:

Code

example.com {
    root /var/www/example.com
    file_server
}

Caddy handles getting, installing, and renewing certificates for you. It's pretty magical.

Here's the same configuration if you just want HTTP (no HTTPS):

Code

http://example.com:80 {
    auto_https off
    root /var/www/example.com
    file_server
}

tl;dr Caddy is magical and more people should use it.

SSL certificate have support issues on older machines and older browsers

This is true. But as my comment demonstrated, any network-capable computer built after 1991 probably can be made to access any modern HTTPS server. It might just take some work. I agree that it introduces a compatibility challenge, but I don't think it's that bad.

I mean: JavaScript, CSS, and even some modern HTML features lack good backwards-compatibility the way that most people use them, too! I'm not saying that all efforts to be inclusive are wasted... I'm just saying: keep priorities in mind! Go back far enough and technologies like cookies and tables become a bit dicey, and text-based browsers lack image support. Sure, some of us are crazy enough to try to write our sites in a way that these things don't become a problem for anybody... but not everybody will!

The worst one, WORSE than no SSL at all: Your SSL ceritificate has expired

You're 100% right; this one's way overblown. What a mess these screens are!

Luckily, you took my advice earlier about Caddy (right, right?) or otherwise used ACME/Lets Encrypt e.g. via certbot, to ensure that your SSL certificates are always renewed with a month to spare. These things are pretty well-automated nowadays. It used to be a pain, but it's mostly a solved problem now.

You moved domains and now you get the same a similar error as above because the domain doesn't match the certificate's specifications.

Nope, just get a new certificate! Again, I'm going to sing the praises of Caddy. Suppose you move from example.com to example.net. There'll be a brief period where you have both domains and you're redirecting people across. Here's what your configuration looks like:

Code

example.com {
    redir https://example.net{uri} permanent
}

example.net {
    root /var/www/example.com
    file_server
}

You do that... and Caddy will automatically solve all the certificate issues for you. I mean: they're not hard normally, but you need to keep focussed. But again: Caddy makes it really, really simple.

(I guess this is turning into a thread where I gush over Caddy. It's not even the first time!)

I've more to say, but it deserves its own post, so I'll pause here for now...

[Dan Q]

Continuing my "yeah!"/"nah!"/"kinda!" on some points @Rubbereon made in another thread:

Then, something I haven't mentioned is that they may cost a lot, at least the good ones. I

SSL Certificate Cost

You've fallen prey to marketing bullshit, I'm afraid. In almost every case, a free SSL certificate from Lets Encrypt is equally good in every way as a premium one from a big commercial certificate authority.

Let me explain why by way of a history lesson:

When HTTPS was first invented (alongside a couple of competing protocols like SHTTP!), the very first version worked like this:

1. It only worked in Netscape Navigator.
2. A https:// site needed to use a certificate signed by Netscape.
3. And it only really got used on Netscape's own websites.

Once they'd proven the concept (and made a few fixes to security mistakes they'd made along the way), the next version came out, and this is the version that every other browser copied. Instead of the certificate having to be signed by Netscape, now it had to be signed by one of a list of companies pre-approved by Netscape. Other browser manufacturers had their own lists of pre-approved certificate signatories, but they often overlapped.

These are the Certificate Authorities. They're a bit like... notaries. In that: anybody can be one if they can go through the right steps, but they're only as good as they are trusted. You can be a notary but if nobody trusts you then they're not going to trust when you witness a document, right? Same deal.

So it's the mid-to-late 1990s and you're starting your own Certificate Authority and you want to get onto the pre-approved lists of the big browsers (and operating system manufacturers, as time goes on). How do you go about that? Initially, it varied from browser to browser, but it was basically a combination of two things:

1. You prove that you know how to run a certificate authority in a sensible way (keep the root keys offline, rotate the secondary keys, blah blah, lots of procedural checks),
2. You demonstrate that you can write a policy document that promises that you'll work in the proper way, and,
3. You pay a lump of money to the browser manufacturers.

That "lump of money" clause is why the original HTTPS certificate authorities had to charge. It cost a lot of time and money to get onto Microsoft and Netscape's good list, so you'd only manage it if you have investors who'd stump up the cash in advance... and you'd pay them back by selling certificates for $40, $80, $200 or whatever.

The race to the bottom

Of course, these early certificates were functionally all identical. Who cared if your certificate was signed by Verisign or DigiCert or whoever, so long as it worked. They were all equally "secure" as far as their cryptography was concerned (okay, there's a slight exception and some hand-waving here because of export and import embargoes on high-grade cryptography, by which I mean 128-bit cryptography in the 1990s, but let's ignore that weird bit of history for the time being...). They still are.

Speaking as somebody who did buy SSL certificates in the 1990s... it used to be much harder work. The "policies and procedures" that the CAs invented in order to get the blessing of the browser manufacturers were pretty robust: I've had to show personal ID (passport), proof of address, and proof of ownership of a business to get what would today be considered even the most basic certificate.

But because the certificates themselves were functionally identical, the marketing was key. If a CA could turn-around a certificate request faster than their rivals, and for cheaper, then they'd sell more certificates! So certificates got faster to validate (we eventually settled on "domain validation", where you prove that you control a domain name and that's enough: that's still how the vast majority of certificates are set up) and they got cheaper, until they got as cheap as any CA was willing to go... and then they sat there just about forever.

And... it felt like a cartel. A conspiracy. All these CAs, nominally-competing with one another, taking your money to do nothing more than to check that you controlled a domain name, just so you can get the magic "green padlock" icon when people visit your site. Total bollocks.

Also: some of the CAs turned out to be... not-so-trustworthy. Some were controlled by nation-states whose oppressive governments used them to make fake SSL certificates so they could steal their citizens' traffic, for example. Others didn't actually do the checks - even the domain checks - they claimed to, allowing attackers to spoof certificates. It was a mess. There was a big cleanup, and standards bodies were formed, and eventually it all got better.

But it's little wonder that folks like CACert set up. CACert came up with a "web of trust" model, backed by freedom and open source and they were finally getting there with winning the argument that they should be allowed onto the blessed lists... when Lets Encrypt came along and solved the problem a faster way! Lets Encrypt was founded as a nonprofit and uses donations (mostly from pretty big companies who want a more-secure Web) to do all the procedural and payment stuff... so that they can give away certificates for free. They also do a few other cool things, like very short-lived certificates (which are more-secure and helped encourage the entire industry towards better automation of renewals etc.). tl;dr Lets Encrypt are awesome.

What's a CA to do?

Suppose you run a profit-making CA and you get wind that Lets Encrypt is on the horizon and is going to decimate your business model. Here's what you do to save your profits (okay, strictly in fact some of these initiatives were already underway by this point, but they certainly accelerated in the wake of Lets Encrypt and friends):

- continue to sell DV (domain verified) certificates to people who don't know better - if you can't tell the difference between a free one and a paid one, you might assume the paid one is "more secure" (it isn't; and in some ways it could be less-secure if e.g. it has a long lifespan)
- sell OV (organisation verified) certificates: these tend to say the name of the owning organisation in them, if you bother to click through to them, rather than just the domain name; also, they tend to come with a guarantee - e.g. "if an attacker breaks your encryption while you're using this certificate, we'll cover you for up to $1M" kind of thing. That appeals to some ecommerce sites, for example, but in reality the certificate is no more secured against the cryptography being broken than a DV one... you're just getting a bundled insurance policy with it.
- sell EV (extended validation) certificates: these usually require even-more-stringent checks that you are who you claim to be, and for a while browsers would give you an entirely green address bar if you had one! These are sometimes more-secure because they have to support standards like OCSP (which allows certificates to be remotely-revoked by their owners)... but in practice those standards get supported by Lets Encrypt etc. anyway so in practice the security's just as good. And people have demonstrated that the "green bar" can be exploited; e.g. the infamous demonstrative Stripe Inc. attack.
- Other kinds of certificates: CAs have pivoted hard into code signing certificates, which are useful because the "app stores" are the same kind of locked-down hellscape that the Web was during the first browser wars; email signing certificates are useful but a CA isn't, and never was, the best way to do this (web of trust + PGP/GPG for the win!), brand recognition certificates (which are the big thing right now if you want to get your logo alongside your company's emails when they land in GMail) etc.
- Pivot into other industries: some CAs migrated towards registry services, DNSSEC, security consultancy, domain registration, etc.

I can't be bothered reading all of that... what's the actual difference between a free and paid-for certificate?

A free certificate is fine. For everybody, even for business purposes. The level of encryption is identical to a paid one.

The more you pay for one, the more-likely you are to:
- get a longer-lived certificate, which is a benefit if you're doing things manually (but you shouldn't be doing things manually because that's a security problem in itself)
- have to prove your identity or your business identity, and get that information recorded in the certificate (which might be useful if you want to reassure your customers that you really are "you", but they probably won't see it anyway and even if they do then it probably doesn't prove any more in reality than your domain name does)
- get insurance that'll pay out if the cryptography itself gets cracked and you lose money as a result (so long as you follow best-practice guidelines about server configuration, and if you do that anyway then you get the same benefit, and if current-grade encryption gets broken we're all fucked anyway and money will mean nothing so what good is that insurance going to do you, really?)

So yeah: the takeaways are:

1. Use a free certificate (unless you're one of the 0.01% of people who really have a need for something else, but you probably don't), and
2. Automate its renewal (certbot or Caddy are my favourite approaches because they're so easy)

[schlime9k]

@Dan Q I always love the (not-so) little history/technical lessons you give on here, and this one was quuuuite an interesting read. I never knew about the history of HTTPS or SSL (maybe that's because I'm too young to have known about that, I'm a Windows Vista kid ) so it's cool to know there was a war over the protocol AND the certificate type! History repeats itself yet again (VHS vs. Betamax, DVIX vs. DVD, HDDVD vs Blu-Ray, probably multiple other ones I'm forgetting)

In almost every case, a free SSL certificate from Lets Encrypt is equally good in every way as a premium one from a big commercial certificate authority.

This is very important to know, especially when just starting out on the indie web, trying to set up a website, you got your domain and you're like "what? I need to pay for that? ... okay..."

STOP!!! PLEASE DO EXTRA RESEARCH!!! You can save yourself headache and money by reading up, do NOT get scammed on the web, it's really easy to do so!

[Rubbereon]

I will say upfront to give context that on the other thread the person I replied to and Melooon's first paragraph (should've read the entire comment my bad) vaguely alluded that unencrypted websites HTTP should be shunned, that anybody using them should upgrade to HTTPS and linking to them should be banned from melonland (Which isn't true ofc, Melooon said they would fix it on the same comment, again my bad for only reading the first paragraph and stopping there) if not from as many places as possible because they are a uber™®℠🅪 giga™®℠🅪 massive™®℠🅪 planetary™®℠🅪 risk™®℠🅪 when it's not true by a large shot, so I jumped quickly into the discussion and left it at that. I did that because not only was I worried it was not gonna be fixed, thing that can be common occurence (there's a real 'wontfix' tag on github and other bug trackers and i've seen it pop a few times) and because I empathize with op since I was under the impression that getting a certificate is or can be extremely daunting.

I am not super interested in arguing about the validity of HTTPS, but after reading all of what was written here I noticed there's some misinfo, and I wanna comment on that as someone who is well-versed in operational security and kind of obsessed with protecting my privacy.

A bit of an oversimplification, even where it's nominally true. Let's say for a moment that "all" HTTPS does is encrypts your connection.

First, NEVER use a public Wi-Fi to do important things ever, even SSL's not gonna protect you, anybody competent enough will see

• What websites you use.
• What requests your computer make so even if you do not use your browser, you are at risk.
• What data you are sending and receiving if the encryption is NOT asymmetric and the hacker knows how to decrypt your connexion.
• How you and your computer look like (half-joking, but we're talking public Wi-Fi in an open space)
• In worse case scenarios, they can infiltrate the computer and see what's on it or infect you with a virus if some ports aren't closed properly (or via exploits), however that reaches a point of paranoia, so while hypothetical it's unrealistic.

At any rate, if you wanna be safe, use a VPN or tor. HTTP and HTTPS are utterly irrelevant in this situation, it makes very little difference for you because you can and will be hacked on both if anybody ill-intentioned is connected to the Wi-Fi. The 6 bullets points are cute because there are like 100 liabilities and things a hacker can do in total on a public Wi-Fi in most circumstances, you've just removed 6 of them by being on HTTPS, well it's down to 94 now. The only way to drop this number to 0 is with a client-side encrypted virtual network to browse while having some kind of custom firewall/whitelist active to prevent external intrusions, these are your only options.
Oh and actually, I did some research while writing this and turns out this point ain't completely true: "1. redirect your request to their own server; they can in some circumstances block it, but they can't spoof it". DNS is not encrypted because it goes through TCP and UDP, so DNS spoofing can be used to redirect to an arbitrary site. "DNS over HTTPS" exists at least on Windows and maybe Linux, but I think it must be enabled first and it's only available on windows 10 and 11 if we're talking strictly windoze. That also begs the question of "what else" isn't encrypted when you perform an HTTPS request.... Get a vpn srs.

Second, while I never bothered to learn the specifics of SSL encryption, it's interesting to learn that it uses PGP, has non-repudiation, verification, etc I just guessed it would maybe use SHA256, but this begs another question, why can't *I* make the certificate myself. I know I'm getting ahead of myself here, but I've generated PGP keys before, they are even widely used in email groups, so this implies a level of complexity that makes SSL certificates more or less secure. Anyway back to the point itself, those are things that are nice to have, but it's not super convincing tbh. It feels like the png to webp arguments, I mean yeah it's nice I guess, but png can be compressed too so why should I care? (don't derail the discussion if you have something to say, make a new thread, I also have an entire blog post discussing what's the best image format of all time and that goes further in depth. I'm a furry artist and an occasional shitposter after all, that's gotta be my area of expertise).

Third, you can verify the user by their ip address, even if an ip makes a request but then another pops in during the request the server can send a "Bad Gateway 502" error, this is something I know Google does because profiling ip addresses is one of their dreaded "supercookies" by the way, and the HSTS thing I've never cared about that because my librewolf (using my firefox profile I should note) was set to automatically direct me to HTTPS all the time even when the website doesn't support it so I've had weird problems in the past thanks to that, but basically even if I just write "website.com" in the address bar it will send a request and resolve to https://website.com first automatically. I'm pretty sure all browsers do that by default now, when I installed Brave for the first time it did that.

Overall, you have maybe 1 or 2 okay arguments, but everything said there is just "eh". One argument ignores the massive elephant in the room, another feels incomplete and yet another relies on "old knowledge" rather than modern norms because browsers always default to HTTPS now.

Also I will add that I highlighted "far more" in my original comment because it was a huge overstatement. Yes it's more secure than HTTP, but after you've read everything I said above and below, "far more" is an exaggeration.

"Web 2.0" and "Web 3.0" are marketing terminology, not standards. Ask three people what they mean and you'll get four different answers, and none of them are necessarily "wrong".

Yes, web 1.0 and web 2.0 aren't really all that well-defined for the most part, but it's vaguely understood by most that web 1.0 is from before 2000 (when everybody had their own websites) and web 2.0 is from after 2000 (with the rise of social media). So, while there are outliers like angelfire and amazon, the absolute majority (like 99.9%) of websites are static pages with no interactive content beyond flash maybe. In fact, this is why "yesterweb" as a word even makes sense at all because that implies there was a web BEFORE the current web. I think most if not everybody here has heard of the yesterweb movement because just like nekoweb and neocities, melonland is a part of it even if it's not exactly static, it's more looks and aesthetics over being functionally web 1.0, anyway that's besides the point.

The funny thing is even Aol was static at the time, no login screen because it was instead an app installed on your computer, now I'm not american and I was born a smidge too late to ever enjoy dial-up internet even if I was, but I can imagine that a lot of "would-be" services like payment processors (the only one I recall from before 2000 was Paypal and it was started at the tail end of the millenium kinda proving my point), registrars, online retailers, art galleries and government websites were static during web 1.0.

So I'll give it to you that Web 1.0 and Web 2.0 as terms are fiddly and don't have a widespread definition, but you are actually wrong about Web 3.0. It is also known as the semantic web as defined by the literal W3C: https://en.wikipedia.org/wiki/Semantic_Web
This is why all your favorite websites follow norms in the address bar or that they have tons of useless divs concatenated on top of each other. I would go as far as to argue that html 4 and 5 are "pioneers" of web 3.0 with their introduction of additional tags like <nav>, <header>, <article>, etc.

One version of the web I forgot to mention in the reply originally was Web3 (not the same thing as the semantic web despite the name). It was invented around 2020 by cryptobros to describe blockchain web technology especially nfts. So at its most exclusive definition, web3 only refers to the blockchain in conjunction with the web, and at its most inclusive (and the definition most people go with to reclaim the term from cryptobros) it means any form of decentralization on the web including bluesky/atproto and the fediverse.

If that can help you picture how my train of thought works, each of those "eras" aren't just [version number] + web, they all have a name too just like the semantic web.

• Web 1.0 is also known as the World Wide Web (where the "www" came from). It describes the internet as a place you can reach no matter where you live in the world and was a major selling point of web 1.0, whereas as it was originally designed in the 70's and 80's it started off as an intranet.
• Web 2.0 is also known as the Social web or the Participatory web. This is when the web began to be centralized around social media, throughout the first decade sites like Google+, Twitter, Facebook, Tumblr, Deviantart and many others would sprung up. Basically, all of web 2.0 was, by design, not static.
• Web 3.0 is also known as the Semantic Web. Read the wikipedia page I linked, it's a bit too complex for me to explain.
• And Web3 is also known as the Decentraweb. This marks the era of blockchain, atproto and the fediverse.

The big attack vector right now is cryptominers. If an attacker can inject JavaScript/WASM that mines Bitcoin, they can burn your battery and clock cycles to make themselves money.

You are right, but this is misleading. The attack is often performed on HTTPS websites owned by the attackers, not HTTP, that's why I said HTTPS does not guarantee you are safe. Furthermore, as a side effect of the attack vector being widespread enough, this means that the javascript has been identified and webextensions like ublock origins will detect it even if it's a man-in-the-middle attack. When I mentioned that in my original reply, I was thinking of "html swapping" or whatever it's called where you request a website's page, but instead of coming from the intended webserver it comes from the attacker, that's obviously not a good thing if you are trying to sign to Paypal.

Attacks like these no longer exist and you would be hella foolish to click on an iframe with a service worker, it's more likely to happen on a HTTPS website too because like I said Google doesn't like HTTP anyway. Speaking of clicking on things you shouldn't, that reminds me of that fake captcha attack that makes you run a (I think batch?) script through cmd. This attack was done exclusively through third party fake HTTPS websites posing as legitimate and I highly doubt a yesterweb site that lacks any certification will ever have a random google captcha sitting around for this fake captcha to replace it in a hypothetical man-in-the-middle, and even if we assume the would-be hacker puts a giant warning screen with the fake captcha in place (think of something like cloudflare's verification) I would just leave at this point because I know this is fake I can tell it is fake, I would be hard-pressed to find ANY http website with some kind of anti-bots measures. All of this is an example where you are actually SAFER on a HTTP website than a HTTPS website due to the attack vector casting a wider net on HTTPS, and HTTP-only sites with widgets and whatnot that were not there before are so suspicious that nobody's falling for that.

So while your argument is valid, in short it's not that strong because stray javascript is not only uncommon and likely to be blocked if it has been added to a blocklist (wannacry was novel at the time, so it managed to get many people before it got stopped), but every attack that could use stray javascript would rather rely on the supply chain attack vector or impersonate another website to lure in unsuspecting visitors either way because they are more likely to make a lot more money from their attacks in inpunity.

I think I did a poor job at explaining what I was getting at in my original comment, but the general idea is that javascript that steals your credentials and makes you install malware was from decades ago. About the cryptominer attacks, I've never considered them because I thought they were attacks done by websites directly (again that have a SSL certificate) and not through man-in-the-middle attacks, at some point it was even normalized as a valid method of monetizing your website. I wonder where you got that part from because I have never heard of cryptominer injections before.

They've gotten pretty easy nowadays,

I genuinely didn't know about caddy, so do keep telling everybody about it because if there's an easier way to install and renew certificates everybody would like to know it.

There was a chatter in the homepage's chatbox that had to reach out to their web host provider (maybe registrar I dunno) because they had problems with their certificate.

Putting a certificate on my site (besides other bs like AI requests and spambots) is one of my biggest concerns and I'm worried that running my website self-hosted would as a result be more frustration than it's worth.


Responding to the second post now:
To paraphrase what I said earlier on this reply, I have doubts since certificates are so complex that you literally can't make them yourself you HAVE to rely on Let's Encrypt or whatever for your site to be a valid HTTPS site. So there is probly an asterisk or a caveat somewhere in there that I'm not aware of that would make a certificate better than another because it was made by Google or something like that, though I have no idea personally and this is really bugging me how certification is a closed environment where only a few companies are allowed to make them pretty much.

Dan kind of touches on why it's such a closed down system, but that ultimately doesn't explain why I can't make a SSL certificate for my own website today if I felt like it, despite apparently being pgp-based.

And yes another thing I knew and Dan eventually called it out, the address bar would turn green on some HTTPS sites and my assumption was that they were way more secure relative to other HTTPS sites, now if that's a myth and fake well I don't mind saying I was wrong, but I kind of need proof or a lengthy explanation given that certificates must be issued by third parties..



Again, I will reiterate one more time that HTTPS is better than HTTP and every website should preferably have SSL encryption, but all of this was very unnecessary I feel like, if somebody's web 1.0, static, retro, website doesn't have that, so what? They're not getting all their visitors hacked just by having no encryption come on now this is silly.

[Dan Q]

A lot of thoughts there @Rubbereon. Just wanted to pick up on one as a matter of importance:

Actually, yes, you can make your own certificates

1. You absolutely can make your own SSL certificates.
2. And, in fact, you always should. If somebody else made your certificate, that would be significantly less secure!

When we talk about an SSL certificate we actually mean two things. Either (a) the public part of a split-key cryptographic system, or (b) both parts (public and private). Again, just like other asymmetric cryptography, the public key is derived from the private.

How to make your own certificate (and then optionally get it signed by a CA so it's useful for HTTPS!)

So yeah: the process of setting up HTTPS on a website, if you were to do it all the slow way (and while I used to have to do this a lot in the 90s and 00s, almost nobody does it all by hand any more!) is:

1. Generate a private key (you can do this by typing e.g. openssl genrsa, though you'll probably want to go a little further than that these days!)
2. Derive a public key (e.g. openssl rsa -in <key file you made above> -pubout
3. That's now enough that you could install it on a webserver! But... your users will get warnings because nobody's vouching for that certificate!. If this were Gemini, which uses Trust-On-First-Use instead of certificate authorities, you'd already be done!
4. But supposing you want a Certificate Authority to sign your certificate, you need to generate a Certificate Signing Request (CSR); so you run openssl req -new -key <key file you made above>. The CSR contains a copy of the public key and some other metadata (whatever you want to be "certified" as the owner of, e.g. your domain name, or company name, or whatever).
5. You send that CSR to a Certificate Authority, and they do whatever their "checks" are. Nowadays, if you're using ACME, a domain verification check might just involve the CA telling you "put a file at example.com/.well-known/acme-challenge/<a random string they choose>, containing <a different random string they choose>. You do that (or rather, certbot/Caddy/etc. does it for you!), and the CA are assured that you really do control that domain.
6. So the CA signs your certificate. Which basically means, they add a message that says "we, LetsEncrypt (or whoever), confirm that the bearer of the private key associated with this public key has proven on this date that they control example.com, and we'll vouch that they will probably continue to do so for the next 30 days", and then they sign the whole thing using their private key.
7. That's the version of the certificate you end up installing: the one that you generated, but that a CA "signed" for you.
8. When a web browser connects to your site, it gets a copy of your certificate and verifies it: Is it in date? Do I trust the CA that signed it (which might involve going through a "chain" of countersignatories until it gets to one in its pre-trusted list)? Has it been revoked (OCSP)? Does the domain name match? Etc.
9. Assuming everything checks out, the web browser comes up with a symmetric shared secret key, encrypts it with the certificate, and sends it back to the web server. The server decrypts the message using its secret key (the thing you made in step 1!), and now the two parties have a shared secret they can use to encrypt their communications.

I've breezed over a lot of steps, but that's the essence of it all.

Why is this something everybody should know

A Certificate Authority is nothing more than a holder of a certificate that your web browser already trusts. Which means that anybody who has ever had unsupervised privileged access to your computer could have invented their own certificate authority, pre-installed it "for" you, and could be signing spoofed HTTPS certificates.

I know because I've done this as part of SecOps/penetration testing/ethical hacking work. And also because I know for a fact that some employers, educational establishments, and less-ethical hardware providers have been known to do this!

So yeah: if you're on a computer provided by your school or your employer and you go to a https:// site, it doesn't guarantee that the connection is encrypted end-to-end, because you can't trust the computer you're using. Just be aware! There could easily be a middleman decrypting, spying/logging, and re-encrypting to pass it on. You can check though, if you're sufficiently paranoid: see which CA signed the certificate a site is using by clicking the shield/padlock/whatever in the address bar, and compare their "fingerprint" to a trusted copy (all the big CAs have pages on their websites where you can get the fingerprints). Here's the fingerprint for the root certificate verifying forum.melonland.net, for example (obviously you can't conclusively use that to verify that you're not being sniffed right-now, if you're using an untrusted computer, because that page could be spoofed by a particularly dedicated attacker, but you see my point!).[/font]

[Dan Q]

First, NEVER use a public Wi-Fi to do important things ever, even SSL's not gonna protect you...

At any rate, if you wanna be safe, use a VPN or tor. HTTP and HTTPS are utterly irrelevant in this situation.

Actually, HTTPS adds valuable security even if DNS is compromised!

Here, you talked about the fact that (for many people, much of the time) DNS is not encrypted. You're right, that's a risk, but it doesn't actually undermine HTTPS (too much). I just wanted to call out this misinformation! For example:

1. You're on dodgy cafe WiFi.
2. You go to https://danq.me (hello!).
3. So your computer makes an encrypted DNS request: "what's the IP address of danq.me?"
4. The attacker steps in, and answers the question... giving an IP address belonging to the attacker! (By the way: DNS isn't the only way to pull this off on a LAN: you can go lower-level and use ARP poisoning. Or just skip all the steps and send rogue DHCP responses that make everybody route all their traffic through you. The sky's the limit!)
5. Your web browser connects to danq.me via HTTPS; actually they reach the attacker's server.
6. But whoops! The attacker doesn't have a SSL certificate (that your browser will trust) for danq.me, so you don't get to connect; your web browser says "warning! this site isn't trusted". The attack is foiled!
7. In the specific case of danq.me, because I've arranged for it to be on the HSTS Preload List in the strictest possible way, any modern browser will refuse to let the user connect via unencrypted HTTP, so a downgrade attack isn't viable. Also, it'll refuse to let the user "bypass" it without going deep, deep into the developer-mode settings: this isn't just a "trick the user into clicking 'continue anyway'" job!

Want to see a a demo of what I mean?

I've attempted an attack against myself at the domain name https://insecure.danq.me/. I've pretended that I don't have control over that domain, so I can't get a reputable CA to sign my certificate for it. Try going to that website and you (should) find that your browser stops you.

In this example, the attacker (also me) was able to redirect the traffic to their own server, but wasn't able to provide a certificate that satisfied your browser. Even though DNS was compromised, HTTPS saved the day..

Bonus points if you can work out how to get a web browser to work around that security protection. If you make it (i.e. you manage to become the victim of the attack!) you'll see a message that begins: "You made it to insecure.danq.me!..."

[Noah_S]

There was a chatter in the homepage's chatbox that had to reach out to their web host provider (maybe registrar I dunno) because they had problems with their certificate.

That was me.

So here's the full story that I glossed over in the shoutbox.

When I was looking for a permanent host, I decided on host-unlimited in Germany. I have what they refer to as web-space. It was cheap, European and met my needs. Domain and Let's Encrypt certificate are included in the price. So I signed up and chose my domain name. ArtNoahS was already my username in many places, so that was easy.

I picked a time when I'd be available for direct communication with the host, so they could confirm the info about myself that I had entered, and we did that. After that I got to start making my website.

I have access to 2 different control panels at this point. The one attached to the host where I can do things like renew the website, and a plesk control panel where I can upload and edit files on my website, access my SQL database and so on. It's through the plesk control panel that you ask for a certificate. Since Let's Encrypt was included, I went with that one. I was given an acme code to put into the DNS in the control panel. I went to DNS on the plesk control panel, and saw that it was already there. The instructions had said that DNS propagation can take a while, so I waited. When nothing happened, I first thought I had gotten unlucky with the timing and it was just taking extra long.

After a while, I went to the host control panel and opened a support ticket and explained the situation. They let me know that the host control panel also had a DNS settings thing where it hadn't been entered automatically. They did it for me, and when I got up the next day everything was working.

If you are paying for hosting and run into something like this, they will want to help you because they want to keep you as a customer. I initially build a skeleton version of my website on a free shared host, and I was more left to figure things out myself there. Everyone who ran into problems, including a massive downtime (one and a half months, during which I moved to my German host), were just told to upgrade to a paid plan. And they did other shady shit, like blocking you from installing something that would automate backups. Moving and getting my self-made codes with me during the downtime required being able to read an SQL database.

In the process of getting my current domain, I also had to confirm that the address I had provided the German host with was correct by sending the people in charge of the .eu domain proof in the form of a picture of a letter one of the local authorities sent me that has my name and address. I don't know how it works for other top level domains, but there are restrictions on who can own a .eu, and they had to confirm that I was allowed one.

But I don't think worry about getting a certificate working should stop anyone from getting their own domain because the people you are paying will want to help you so that you keep paying them.

[Noah_S]

I've attempted an attack against myself at the domain name https://insecure.danq.me/. I've pretended that I don't have control over that domain, so I can't get a reputable CA to sign my certificate for it. Try going to that website and you (should) find that your browser stops you.

And that is a bigger browser stop than people got when visiting my website before I had the certificate set up. Firefox didn't give me the option to proceed anyway.

[schlime9k]

... on the other thread the person I replied to and Melooon's first paragraph ... vaguely alluded that unencrypted websites HTTP should be shunned, that anybody using them should upgrade to HTTPS and linking to them should be banned from melonland ... if not from as many places as possible because they are a uber™®℠🅪 giga™®℠🅪 massive™®℠🅪 planetary™®℠🅪 risk™®℠🅪

Hi, that was me, and that was also partly my fault as I probably worded my comment poorly, as with anything that comes out of my mouth / keyboard. I do not want to vaguely allude to the shunning and/or destruction of standard HTTP at all, we'll lose a lot of important sites and information if that happens. HTTP should still be very well supported. All I meant to say is that HTTPS should be the more common of the two, especially for important, high-traffic websites because of its more secure framework. I mean, you even said so yourself so we agree with each other <3

Again, I will reiterate one more time that HTTPS is better than HTTP and every website should preferably have SSL encryption.

And I also agree somewhat with your last statement on not everyone needing HTTPS for static, "web 1.0" sites because it's sometimes not necessary and can be a headache for some to get the certificates set up properly, though Dan has made some great points himself about that specific topic. However, that shouldn't be a reason to entirely write off HTTPS, though I might be misreading what you mean by "but all of this was very unnecessary I feel like"...

[Dan Q]

Personally, I think the CA system for web certificates was flawed from the start.

Encryption turned out to be important enough that it should have always been acceptable to run HTTPS over a certificate that wasn't signed by a Certificate Authority (what we usually call a Self-Signed Certificate). This is exactly how Gemini works, for example.

The benefit of this is that it makes HTTPS work everywhere, super-easily, and everybody gets the benefit of encryption. If this had been the model from the start, we'd have never seen attacks like Firesheep because by 2010 HTTPS would have become the norm.

What this wouldn't give us would be any kind of validation, and Domain Validation is useful because it helps prevent spoofing (e.g. I can't just send fake DNS/ARP/DHCP responses and trick you into going to "paypal.com" which is actually my website). But I feel like this could have been worked-around: all you'd need is for the "padlock" icon etc. to only appear on validated HTTPS websites.

That way: instead of a two-tier system where there's (unencrypted, unvalidated) HTTP websites and (encrypted, validated) HTTPS websites... there'd be a three-tier system where there's (unencrypted, unvalidated) HTTP websites, (encrypted, unvalidated) HTTPS websites, and (encrypted, validated) HTTPS websites. Only the last category would get the padlock icon, not "warn" you when you type in credentials and credit card numbers, etc... but the second category - the "new" one - would still provide benefits in terms of binary transmission, pipelining, encryption, and all the other good stuff we get from HTTPS these days.

Anyway: that system would inevitably have evolved into our current system once Lets Encrypt came along, but it would have gotten us to a more HTTPS-friendly place up to a decade-earlier, and it would still make it easier to set up a development server, and it would mean that most sites didn't get scary ugly warnings when their certificates expired (the webservers could just generate replacement self-signed ones and carry on, albeit minus the padlock icon).

That's how I'd have implemented HTTPS, with the benefit of hindsight. But hindsight's 20:20, isn't it!

[Dan Q]

Just realised, an alternate history of HTTPS could be the next "alternate history of the Web" I write, following my one about how P3P, had it survived and evolved into something actually useful, could have saved us from all of those cookie banners and privacy policy checks today.