Website hosted on ESP32 (opens in new tab)

Loaded fine for me now :D

I would blame ISP's and public WIFI providers before blaming browsers for preventing ISPs and/or anyone else from MitM/malware/injection attacks.

> I wondered why in the heck a static web site running in a resource limited environment would even attempt to run https.

Err, I don't think it is. This is in the response headers:

    Server: nginx/1.18.0 (Ubuntu)

Getting nginx (let alone Ubuntu) running on a ESP32 would be a seriously impressive achievement.

The web site also says:

    Once it is running, you can access your website by entering your ESP32's IP address in a web browser. For example, if your ESP32's IP address is 192.168.1.100, input http://192.168.1.100 in your browser.

The site works for me now, and I'd suspect it to be able to support a minimal HTTP (not HTTPS) server if it ran natively, but then we also have this:

    You need to download micropython.py file and place it in the root directory of esp32.

So it's written in Python and a chip with the compute power of a potato. It would be interesting to compare it to the same thing done in C or Rust.

yes, you got it right its due to that odd message web browsers show for non-https websites. This HTTPS/TLS has been added using nginx on different server, also to support some load. The website is still under lot of traffic, however nginx is doing good on its part.

So here is nginx running on a real computer and a homebrew webserver running on a potato, and your theory is nginx is the limiting factor. And it’s all the fault of encryption and the browser cartel.

In what way is requiring encryption security theatre?

There are multiple TLS stacks for microcontrollers, that are like decade old and running on devices much less performant than ESP32.

Maybe it's more than security theater. With mandatory TLS, i.e., encryption plus third party-mediated authentication, the ability to publish a website comes under the control of third parties, so-called "Certificate Authorities" (CAs).

The source of this third party "authority" is unclear. If a CA uses DNS for verification, then the "authority" is ultimately ICANN. And we know that ICANN's "authority" is completely faked up. It has no legal basis. These pseudo regulatory bodies have no democratic process to ensure they represent www users paying for internet subscriptions. As it happens, these organisations generally answer only to so-called "tech" companies.

Effectively, CAs and browser vendors end up gatekeeping who can have a website on the public internet and who cannot. Not to mention who can be an "authority" for what is a trustowrthy website and what is not (CA/Browser Forum).

The hoops that the browser vendors make a www user jump through in order to trust a website without the assistance of a third party are substantial and unreasonable. It seems that no www user can be expected to make their own decisions about what they trust and what they don't. The decision is pre-made, certificates are pre-installed, autonomy is pre-sacrificed, delegated to so-called "tech" companies.

Meanwhile these so-called "tech" companies, who are also the browser vendors, are commercial entities engaged in data collection for online advertising purposes. For more informed users, these actors are perhaps the greatest eavesdropping threat that they face. The largest and most influential of them has been sued for wiretapping www users on multiple occassions.

There are conflict of interest issues all over the place.

tl;dr Even if the contents of the transmission are not sensitive and perfectly suited to plain text, the system put in place by so-called "tech" companies, to benefit themselves at the expense of every www users' privacy, ensures that TLS must be used as a means of identifying what is an "acceptable" website and what is not. Absence of a certificate from a self-appointed, third party certificate authority means "not acceptable". Presence of certificates from first party authorities, i.e., ordinary www users, means "not acceptable".

Because sniffing? And tampering?

An HTTPS server with esp-idf is absolutely trivial: https://github.com/espressif/esp-idf/blob/b4268c874a4cf8fcf7...

The software support is incredible IMHO, it's a huge reason to use these chips. I made some toy temperature sensors with an esp32 last year, they make it so easy: https://github.com/jcalvinowens/tempsensor

The error message "504 Gateway Timeout nginx/1.18.0 (Ubuntu)" suggests that Nginx, running on Ubuntu, is acting as a proxy server and is timing out while trying to connect to the backend server. The SSL cert is on the proxy server.

Shoulda spent the extra $2 for S3

Just kidding, ESP32 in general is great, but the newer ones do offer a bunch of extra stuff onboard for very little more cost/complexity.

poor chip must be fried already lol

thanks !! yes it behind nginx

I remember that PIC project. I don't know if source was ever released, but I recall a lot of folks being very dubious about the claims made.

Quote: The PIC has 1024 words (12-bits) of program ROM, ~256 bytes contain a hand-crafted RFC1122-compliant implementation of TCP/IP including.

HTTP/1.0 and i2c eeprom Filesystem, using 3 to 99 instructions. TCP and UDP protocol stack, using 70 to 99 instructions. ICMP [supports upto ping -s 11], using upto 14 instructions. IP - Internet Protocol, v4, using 68 to 77 instructions. SLIP - Serial Line IP packetisation, about 76 inst Fully buffered UART, upto 115200 bps, using 38 to 56 instructions. Operating system: RTOS with Rate Monotonic Analysis, using 3 to 15 instructions.

Well, given that the modern web has a lot more requirements for security to even permit most browsers to view a site, it makes sense that the base hardware needs have increased noticeably.

There's a big difference between http and https

You'd be a bad parent

Thank god someone said it. That poor ESP32 needs to be rescued from this sadist.

nope, no CDN. It has NGINX reverse proxy

Does anyone have recent information on how much traffic being on the HN frontpage gets you? Would be helpful to know.

I think it will drop most of the traffic, as I posted in load test results. The traffic coming to this is crazy. I can see nginx access logs and requests are not stopping!!

Out of curiosity, what do you use for the server?

I've had good experiences with the HTTP Server component built into ESP-IDF. I see the example in this post uses Microdot.

it was too much traffic to handle for this little poor chip

Came to do my part

yes, I have a static IP and port forwarded. It IP can be mapped to website (dns name) via namecheap and godaddy like services. This is enough to put it on internet

In this setup I added a nginx in between (doesn't enable cache yet) for load balancing.

DNS and port forwarding.

Lol! this is true after posting on HN

Right, like a Beowulf cluster!?

Sat Sri Akaal

Was that a joke? There doesn't seem to be any implication this is running k8s?