They also have a typo on their description...
"AI coding creates a time span isn't long enough to do something new, and it's not short enough to be entirely negligible"
Should say "that isn't long enough" or "which isn't long enough"
Always good to see people who give a shit getting rich off the results of their work /s
Is the conclusion here not that you are asking questions when you should instead have been looking for an existing resource?
The ability to search across the massive accumulation of knowledge we have already built up is a primary skill for software development, and the tut-tut'ing is a way of letting you know that you failed in that endeavor, which should be valuable feedback in itself.
How many people drive their car daily or near daily?
How many people are good drivers?
The ratio of those two values shows, in my experience, that a lot of people are not very good at things they spend a lot of time doing, and are generally unaware of their own shortcomings
The average American spends 4.2 hours a week in the car. A typical 40 year old american has driven around 50,000 miles. For someone to continue to be bad at driving after that much experience, it must be a fundamental limitation on their capabilities for learning, thinking, or understanding. Drive to work any given day in Denver and you will see that a large number of people suffer from those fundamental limitations.
This article seems to present a world where most people the author interacts with can think critically about a complex topic, and are interested in learning or improving themselves. I wish I lived where the author lives, because I have had multiple jobs across multiple countries and never encountered an average population like the author describes.
In that case the NAS company should, at a minimum, be loading their NAS with a certificate signed by a CA owned by the NAS company, where the trust chain for their NAS's certificates are easily available for users to grab and install.
In an ideal world they would load a letencrypt certificate and set up the tooling required to automatically pull down a new one when required.
A NAS company owned CA doesn't offer much of a benefit directly for the plug-n-play users, but it's still better than just a self signed cert, and for people who care about their security even a little bit it can significantly protection.
Most Plug-n-Play NAS solutions will integrate with a web api and/or an app, and it's more common than it should be that NAS'es are exposed to the internet.
Once you control both the NAS and it's clients, there's absolutely no reason not to preload a complete PKI implementation. Even just an installation app which loaded the chain onto any device you wanted to interact with the NAS would be sufficient.
If NAS'es are intended for non-technical people, then any NAS sold should be secure by default.
Allowing self-signed certificates creates a higher risk for MITM attacks.
Sure you can trivially get a letsencrypt certificate once you register a DNS entry, but you can't trivially get a letsencrypt certificate which validates google.com
If you control the local network it's trivial to redirect traffic intended for elsewhere, like "google.com", and trivial to have the server it redirects to present a certificate with "google.com" in it's subject or SAN.
What would happen on a laptop is you would be hit with a certificate validation error because it was self signed, and on the laptop you have the ability to bypass it, but that ability to bypass is very dangerous. Most users will not properly check a certificate before clicking to trust it.
As far as what could be done, "this is a low value device to an attacker" is not a security measure, but beyond that I'm sure that people have bought games on a gamepad, and anything which involves financial transactions has the potential for malicious behavior with severe consequences
The barrier to entry on PKI isn't that it's hard, it seems to be that people just can't be bothered, PKI is among the most google-able tech processes out there
You have to consider the rarity of your use case vs the use case they're defending against.
How often do you think someone tries to connect their gamepad to a local server? Not never, but the total amount of users doing it is probably high tens or low hundreds at most
Compare that to how often gamepad users try to connect to a malicious website - probably hundreds or ever thousands of times a day.
Loosening certificate validation further expose the many less than competent users to risk, and the potential impact both on the customer base and on the product's reputation are significantly higher than the risks of making it cost a couple bucks a year to allow your gamepad to connect to a local server.
For something like a computer, there is a legitimate argument for allowing the user to bypass SSL/TLS restrictions (after some resistance) because laptops are used for development.
I can almost guarantee that the gamepad developers had an options for certificate validation bypass in it's developer options, but they're not gonna expose that needlessly when it offers no benefit, but exposes their customers to additional risk. Your gamepad is likely not a development device after all
I didn't say a "pinned self signed cert is insecure"
I said that self-signed certs are a lazy choice
I also said "allowing the end-user to confirm a certificate offers basically 0 protection"
If an average user get's prompted to trust a certificate they will do so blindly
At most, someone might look at the subject, but it's 0 effort for a malicious actor to generate a self-signed cert with the same subject, which will be sufficient to fool a decent chunk of users
Pinned certificates do relieve the above issue, but it is still a lazy choice that creates increased long term complexity in the configuration of multi-system environments
Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA
Using a CA also allows for use of CRLs or OCPS.
If you have 20 devices configured to trust a given self-signed certificate, and that certificate leaks, you now have to update all 20 devices to remove that trust. If you used a CA and implemented either a CRL or OCSP, then you only have to update the respective impelmentation and all of yoru clients will immediately stop trusting that certificate.
In Summary:
Using an internal CA offers all the potential protections of pinned certificate, with a number of additional useful security options like OCSP or CRLs
Using Self signed certificates creates more work when handling certificate leaks or certificate rotation
Using a CA is the industry standard practice, I highly doubt there is a single outward facing project by a major company using a directly self-signed certificate.
BUT
A self signed certificate is lower effort on the initial setup
"This is good enough because I don't expect anyone other than me will use it" is lazy
What would happen if you connected to your mail client today and you got prompted "Trust this certificate?" showing a certificate with the same subject as the one you generated? Most people would click trust and get MITM'ed
Allowing self signed certificates significantly lowers the bar when it comes to generating a new certificate which can closely resemble an existing certificate
Beyond that, the management of multiple trusted certificates creates all sorts of room for confusion in an environment. Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA
It's 2024, PKI best practices are well known and well documented, anybody still using a self-signed certs on their mail server (or anywhere) is either lazy or stupid.
Plenty of existing applications will refuse to connect to a self-signed certificate on the belief that allowing the end-user to confirm a certificate offers basically 0 protection against malicious actors.
I used logic.ly for a class last semester, we used it for about a month and built up to a very basic cpu. I found it pretty easy to pick up and fun to work in. Wouldn't be surprised if a lot of online computer arch classes use this in the coming online semester.
Glad to see this go public. I am interning for one of the guys working on this project (I am not working on this however) and they seem like good guys. Best of luck in getting funding!
Congratulations on getting published. Having finished the paper I thought it was informative and well written. I just started interning for you guys today and I look forward to an exciting month!
I am currently an intern an The Immunity Project, a YC funded non-profit working on vaccinating HIV. I have been here for only a day so far but I whole heartedly agree. I have been welcomed with open arms, introduced to new and interesting people, and learned thing about the industry I never would have in a college run program. This is only my second time meeting the team, but I am excited to work with them. I will be doing interesting experiments, and legitimate lab work, something not offered in most programs. I also gain access to community between the different companies that is unique and exciting. I definitely recommend this to anyone who gets the opportunity to pursue interning for a YC company.
Always good to see people who give a shit getting rich off the results of their work /s