https://web.archive.org/web/20231105185258/https://esp.khals...
I wish that the demand for security theater in web browsers wasn't so high that they effectively prohibit plain old text transport.
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.https://en.wikipedia.org/wiki/PC1512
While any serious game development was done in Assembly, languages like Python were a plenty to chose from.
So instead of looking down on the project for having chosen Python, as someone that used to play Defender of the Crown at the high school computing club, I marvel to what an ESP32 is capable of.
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".
You have to have a domain to use it obviously. Lucky there are other god's workers like duckdns to work around the domain scam too.
https://letsencrypt.org/ https://www.duckdns.org/
[1] Obviously not referring to any theistic entity here, but more to something like the spirit of FSF or whathaveyou.
- adding another root CA, or
- bypassing HTTPS warnings, or
- taking 10 minutes to set up LetsEncrypt
and for obvious reasons, neither of the first two should be easy
Edit: I got a default nginx/1.18.0 (Ubuntu) gateway timeout message after a few minutes trying to load this page, this is reverse proxied.
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
How do you make the step from breadboard dev to something manufacturable?
There is a nginx proxy. Nothing fancy here but kudo for the tutorial.
A 32-bit CPU is very rich
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.
Of course, no https, but.. it is not a platform limitation, just an undemanded feature: how would you get a https cert for 192.168.0.1 or a similar intranet address where those device suppose to work? They are just not for cloud datacenters
Edit: wow. Some people are super sensitive about what ports I serve text on. Good luck to you all in life.
In this setup I added a nginx in between (doesn't enable cache yet) for load balancing.