Website hosted on ESP32

Its still a single esp32 s2 mini. Its Nginx that is saving this little mcu !!

How can you reliably know that you're not being MITM without HSTS?

Isn't HTTPS needed to stop injection by ISPs?

I agree that not everything needs to be encrypted, but unfortunately a lot of people who browse the web are concerned when the browser complains that something is not secure.

From the browser maker's side, how does a browser know whether something should or should not be secured? They have clearly taken a more aggressive approach to inform users what is going on within the underlying protocol. While I do agree that not everything needs to be encrypted, I also agree that the user should know what is or is not happening under the hood.

Where does logging enter into it? To my understanding, serving traffic over HTTPS doesn't require you to do any additional logging (or any logging at all).

The point about static webpages would be a potentially good one in a world where ISPs and other Internet middlemen are honest and transparent actors, but this has so far proven not to be the case. I think it's in everyone's interest for your static content to reach my browser without ads or tracking mechanisms being injected by a third party.

If everything that didn't _need_ encryption wasn't, then the use of encryption could be suspicious in itself. For my part I'm glad that we've moved to a mostly working system of encryption most things

> Not everything needs to be encrypted. If I'm serving static webpages the only thing I might want to log is the which IPs visited at what time of day.

As a frequent user of public WiFi (mostly at coffee shops, airports, etc.), I prefer that every page is encrypted so that nobody can MITM me/tamper with what I see in my browser, even on plain text pages.

I usually use https://oshpark.com/ or https://jlcpcb.com/ with EasyEDA or Kicad depending on what you're comfortable with. A good 3D printer wouldn't hurt either.

Next step is a system integrator like m5stack.com, either build a nice unit from their library of components and let them worry about the minor issues (power regulation etc). If you're prototyping at home just put them in your own enclosure, if you want to go industrial you can 3d print something that integrates with their stuff (eg user-friendly modules like Core) or use the stamp components.

If you have done all the circuitry want to just print/assemble your own PCBs, sites like PCB unlimited will make up short runs or Digikey will handle larger scales.

I didn't do any breadboarding at all, I just jumped off the cliff with this. I started by designing a 1"x1" PCB in EasyEDA with just the MCU and pin headers, and had five manufactured/assembled by JLCPCB to test the core of it. The first time I'd ever touched an ESP32 was when I got those PCBs in the mail and started trying to program them! It was really fun.

Once I'd proved it worked, I pasted that 1"x1" layout into a larger footprint, and added the sensor, power supplies, and batteries. Again, I had no real way to test any of the new stuff: I just iterated until I stopped finding problems to fix, then had them manufactured. A big part of the fun of this has been having to commit to a design without the ability to test: it really makes you think. I also enjoy the exercise of writing as much of the firmware as I can while the hardware is in the mail, then seeing how much actually works when it shows up.

In terms of bad decisions... I used builtin gpio pull-up resistors for I2C: it works, but the margin is very tight, it's just not worth it (and also means I can't put the ESP32 in sleep mode in some cases...). Wifi uses phase to encode information, so having no RF matching will impact its performance beyond the -6dB I mentioned in the README. The inductor/capacitor values are much larger than necessary. The routing of the I2C lines taking a huge bite out of the ground plane under the switcher IC is dubious. Using 1.5V alkaline batteries is nice because I don't have to worry about burning my house down... but I've gone through 200+ AAA batteries over the last year, and it feels very wasteful.

I learned most of what little I know about PCB design from this youtube channel, I can't recommend it enough: https://www.youtube.com/@PhilsLab

There was no real goal beyond the experience of building the thing and making it work. I use them to monitor stuff like fridge/freezer and HVAC intake/output, and as leak detectors in my crawlspace.

As you'd probably guess, the fixed cost of the manufacturing was extremely high. Unfortunately I didn't write the numbers down... but going from memory, ordering 5 instead of 30 would have only reduced the total cost by ~20%. I remember a weird valley in cost-per-unit at a quantity of 30: my understanding is that JLC combines small orders, so my guess is that 30 of that board was the largest order they were willing to squeeze onto the same panel as another one.

You can make an HTTPs certificate with that in the SAN section, and it should work fine. You can't get one from a publicly trusted provider, of course, but that's fine; you don't own the IP.

In other words, make your own certificate authority for your own machines. It isn't that hard.

Some ISPs modify the content and inject ads in HTTP web sites.

HTTPS doesn't really have to do with whether the page content is sensitive. It's more about protecting visitors from MitM attacks, traffic analysis, and their browser screaming at them and refusing to load your site because it's ""insecure""

One of the reasons is to prevent ISP and other to intercept the page and interject the codes before it arrives to the users. It a common method to put the payload in the http. I believe it called middle-in-the-man method. With https, it reduced a lot of attacks.

There was a news about Comcast interjected a Steam storefront page with a data cap warning on it to a Comcast subscriber. And this happened inside Steam app which was using http at the time.

You're being downvoted, but you're right.

I'm fine serving my personal website under http.

- If someone is worried they'll be found out using my site, then fine, don't use it. This advice is just for my site, and it's fine to desire security elsewhere and in other contexts.

- If an ISP or MITM want to inject some content in my website, then fine. We'll all know not to use those providers. I promise I'm not important enough for this to be a vector someone would want to exploit.

None of the information I have to offer you requires HTTPS. I assure you.

I think it's fine that https is becoming the default, especially for web services. But we shouldn't enforce it. It's an undue burden to have to support all the certificate machinery just to serve some basic info.

We really need to get back to the basic, easy to hack web. Where it took nothing to spin up services on your home machines and serve them as demos to others. That ethos was great.

Everything should be served securely these days. Prior to HTTPS being absolutely king, ISPs here used to inject EXEs with malware and do all sorts of nasty stuff. With HTTPS dominating they don't do that sort of thing anymore as the share of HTTP traffic is so low making ROI very low.

Anyway I'll give you one reason based on the above on why you should serve your content over HTTPS, it shields you from potentially having your visitors be victims of something like this and in all likelihood they will blame you for whatever malware their ISP sent their way... they did get infected from your website, after all.

You can serve to yourself whatever you want, but please don't make other people leak what you've served them.

People can be really tedious when it comes to this subject. Like, for the authenticity use-case, the server could present its certificate followed by a signed but unencrypted page, in a standard way so the browser could check the signature. Then the signature for static resources can be cached on the server (or middle boxes) and no key exchange or encryption is needed, greatly reducing computational needs to serve a page while still keeping it essentially secure. There's also fewer hops in this scenario (so better user experience), and it's easier to do things like filtering with a simpler proxy without needing to install CAs. But no one wants to have a productive conversation about actual trade-offs here.

Edit: in fact, if we used client certs for user identity[0], signed requests could also be used for form submission for e.g. public forums or youtube uploads where you might not care about privacy of the submission itself.

[0] https://news.ycombinator.com/item?id=38129870

Having HTTPS as the only option for a site is an excellent default, both for protecting the confidentiality and integrity content, as well as validating the identity of the site for the client. Maybe a good way to put it is that the vast majority of the site's uses and data needs no protection, but protecting all of it well is probably much easier to do correctly than just selectively encrypting the important parts.

My humble little personal site has largely unauthenticated, static blog stuff. It also has personal apps that nobody else uses, but I want to protect the authentication bits.

You obviously don't need to serve your static blog over HTTPS, but I think it would be nice of you to serve it over HTTPS anyway!

> Some people are super sensitive about what ports I serve text on

If I thought the key difference between http and https was which port it is served on, I’d probably be confused by people’s reaction too.

Likely possible to handle HN load just fine... if the page was static.

edit: page loaded. It's apparently Microdot, a micro web framework running on micropython.

Well yeah, anything is easy if your server isn't doing the work.

My website runs on baling twine and duct tape (...and CloudFlare).

Its good idea, I never tried or probably didn't know much about nginx caching. Will Nginx cache webpage and serve directly without hitting much the esp32 server. I am going to read on it now

Just did it !! Enabling 10m caching on nginx now (It is good atleast now the link will open from HN homepage). Thanks for suggesting this, I should have done it before

Just DDNS

Sorry, where's the assumption it's using kubernetes coming from? All I see in the response is nginx which doesn't imply anything k8s. The blog linked from the page doesn't mention k8s either (nor nginx).

That said, you can run an ingress for a service that's just an externalname reference with the right annotations depending on your ingress controller and I'm pretty sure it'd just work.