Hacker News new | past | comments | ask | show | jobs | submit login

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?




> 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.


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: