Comment by rurcliped | Hacker News Reader

Comment by rurcliped | Hacker News Reader

I have public content that I'm willing to share over the web. To offer it over HTTP, I only need a few thousand lines of code on top of TCP. It's realistic to prove that that code has no memory-safety problems. To offer it over HTTPS, I need to add tens of thousands of lines of extra code related to cryptography. No existing implementation is known to be correct. The popular implementations don't have a strong history of code quality. It's completely reasonable to expect that, over time, new vulnerabilities will be found that will allow attackers to read or write to unintended memory locations on my server.

I totally understand that, by adding a popular but historically unsafe cryptography implementation, I can help web clients to avoid MITM shenanigans while reading my content. MITM indeed is a problem. But, I'm not willing to make that my problem. The vast majority of my customers don't experience MITM data modification while reading my content. The vast majority of my customers wouldn't care if the whole world knew that they have read my content.

Perhaps in the future, code for all the required cryptography layers will be just as provably correct as code for reading the cleartext HTTP protocol. When that day comes, I will add HTTPS. Not before.

I can't understand this opinion. So what if it only negativity affects a few users? How do you feel about ML that produces problematic results for a portion of users? Security is correctness.

I don’t follow.

1. You don’t have to write any code to use HTTPS, it has already been written.

2. Are you saying that since HTTPS isn’t perfectly secure you’re gonna use the definitely insecure HTTP? What kind of logic is that?

From a purely selfish perspective:

HTTP worst case: your reader is harmed.

HTTPS worst case: you yourself are harmed (e.g., if someone finds a zero-day in a cryptography library and uses it to run arbitrary code on your server)

Yeah because nobody has ever found rce bugs in other parts of the http server infra. The only way people get rce on your box is by exploiting tls libs. Right.

HTTP is simple enough I can literally create a barebones semi-compliant HTTP server from scratch. If all it has to do is serve some static pages, I can do this in ~1000 lines or less. I don't need any infrastructure beyond basic TCP/IP. Can't say the same about HTTPS.

Are you seriously implementing your own webserver or are you running nginx or some other system?

I'd even wager that a typical homebrew http server is going to have way more rce problems than an existing stack that includes tls.

I'd say you should be counting the lines of code needed to implement TCP/IP – as well as DHCP, ARP, Ethernet, maybe DNS, and anything else I've forgotten that your server needs to speak. Consider lwIP, the most common implementation of those protocols on microcontrollers: it's meant to be minimalistic, but it's still some ~35,000 SLoC, not including tests. For comparison, a minimalistic implementation of TLS is Amazon's s2n, which is ~12,000 SLoC. Adding s2n to lwIP would only represent an increase in code size of about one third.

Of course, a more typical HTTP/HTTPS server will be using the Linux kernel for networking (with some userland bits for DHCP and DNS), and OpenSSL for TLS – overall representing multiple orders of magnitude more code. But I suspect the proportion between TLS and non-TLS would be somewhere in the same ballpark, depending on how you count.

The problem is that on Linux, the TCP/IP stack is in-kernel, universal for everything on the system, and overall unobtrusive – it mostly 'just works' – while OpenSSL is in userland, has an unwieldy API and unstable ABI, can be linked in many different ways, requires a lot of configuration, and is overall a pain in the neck. So as a developer, the complexity of TLS weighs heavily on you, while the complexity of TCP/IP is something you can largely forget about.

Personally, I think TLS adoption would have been quicker if it had been implemented in the kernel and it just became a switch you could flip in the socket API; something like:

    socket(AF_INET, SOCK_STREAM, PF_TLS)

But for better or worse, that's not how things panned out.

> you saying that since HTTPS isn’t perfectly secure you’re gonna use the definitely insecure HTTP? What kind of logic is that?

Different sort of security. While I don't agree with OP, the logic here is somewhat sound: he is concerned about the threats against the server. It is reasonable to claim that TLS increases the attack surface, because any any vulns in TLS implementation would be purely additive to the potential vulns in the HTTP server.

An option is to write your own web server and have the likes of Cloudflare provide TLS (and a bunch of other stuff!) on top of it for free. Best of both worlds.

>The vast majority of my customers don't experience MITM data modification while reading my content.

[citation needed]. You have no idea if that is the case or not. Too many ISPs inject ads, javascript, or other horrible technologies (flash) in to customers HTTP streams.

Users have no idea if what you are serving them is what they are receiving. If this is content like code samples they can be corrupted my malicious users. If it's political content the message can be altered.

<hyperbolic>I mean, we all know rurcliped is a Nazi, their website said so the other day. </hyperbolic>

Reply on news.ycombinator.com