iOS 18 breaks IMAPS self-signed certs | Hacker News Reader

iOS 18 breaks IMAPS self-signed certs

forums.developer.apple.com

118 pointsmmd45148 comments

I think the solution to this is to:

a) run your own private root CA

b) install the public part of the root CA on your device and trust it (basically the same as many major enterprise end users of android and ios devices need to do already, so this functionality is extremely unlikely to be removed from the operating system)

c) use the root CA to sign a cert for your mail server

Yes it's a bit more hassle than just trying to tell the mail client to trust your self-signed cert that was generated on the mail server and signed by nothing, but I can understand why apple (given the population of hundreds of millions of NON TECHNICAL end users) doesn't want people just blindly clicking through "yes/I accept/trust this server" self signed cert warnings.

I switched to letsencrypt certs for my imap server. Works well, IMO better than the self-signed ones I used before.

I'm using a private ip over a vpn so I don't think that workaround will work for me. I don't really want a public dns record.

LE will issue you a wildcard certificate and it's usable for mail.

i'm just using a hardcoded private ip to connect to the imap server. are you saying i can get a certificate with a hostname of "*" that will match ANY ip address?

No, but you could use DNS for that internal IP. And then you'd have a hostname. Since your IMAP server likely has some way of getting external mail, it is likely that you have a DNS zone and MX records, so adding an A record for your internal IMAP access isn't that much of an effort compared to what you already would have.

If you have mmd45.com as a domain and have MX records pointing to your mail server, adding imap.mmd45.com pointing to your IMAP server should be fairly simple. Getting a Let's Encrypt certificate for *.mmd45.com is all that remains for the TLS part with a valid CA chain. As a bonus you can then also use encrypted SMTP.

unfortunately none of that applies to my setup. my imap server lives in a dmz and doesn't have all that other jazz.

Only thing required for this setup to work: client needs to be able to resolve domain to internal ip.

I have wireguard mesh with a bunch of services that use LE for TLS that have no access to interwebs and not accessible from interwebs.

how are you renewing the LE certificate if the domain is resolving to an internal ip? this seems like a big hoop to jump through.

https://letsencrypt.org/docs/challenge-types/#dns-01-challen...

LE doesn't need any A or AAAA record. The domain must exist in the DNS and you must be able to create records in the domain.

If you're using internet mail you have a domain, so you can do this. The time for self-signed certificates has passed.

A pinned self cert is still more secure than this because you don’t have to trust any CAs.

> The time for self-signed certificates has passed.

This is bad blanket advice and very much depends on use-case.

Software is a collective. A billion or so people get the same software. The time for self-signed certs has passed because supporting that in software for a billion people opens up some of that billion to attack.

The few people who understand the niceties of certs can create a private CA, trust that, and use that CA to sign a regular cert. Doing that is nontrivial, but it doesn't put other people at risk.

LE can use DNS itself as the challenge. It works something like:

- You manage the mmd45.me domain (through a dns provider, say dnsimple)

- You ask LE for a cert for imap.lan.mmd45.me (an address that doesn’t exist, but you use in /etc/hosts or something internally. Or maybe an internal dns server like a pihole or something. The rest of the internet doesn’t see this address)

- LE says “prove you own lan.mmd45.me by creating a TXT record containing <random-nonce> inside _acme-challenge.lan.mmd45.me”

- Certbot integrates with your DNS provider to create said TXT record

- LE sees the TXT record and determines you are the owner, and signs your cert. At this point certbot can just delete _acme-challenge.lan.mmd45.me because it did its job.

At no point does mail.lan.mmd45.me need to be externally resolvable to any address for this to work.

> Only thing required for this setup to work: client needs to be able to resolve domain to internal ip.

It does not. Use DNS validation, that way you can issue LE certs for individual domains as well as wildcard certificates without needing to expose anything anywhere other than a CNAME record for the validation.

This can still work imap.mydomain.com resolving to your hardcoded private ip, put the cert on your imap server, connect by name, done.

This won't work on many home routers that filter out private/local IP A/AAAA records from DNS responses to protect against DNS rebinding.

How many people care about setting up secure connectivity to an internal server but are unable to either disable this behavior or configure their own internal DNS service?

My internal DNS names are served from my router and I'd imagine a lot of the people who would care about this in a home environment are running either open-source or business-class commercial devices that can do the same.

Mine too. It does apply.

Seems to be a safe assumption you have a domain since you're receiving mail.

Go run something like certbot[0] on your mail server. It has plugins to integrate with various DNS providers. (This is who is hosting the zone where you map domains to IPs, not necessarily where you registered the domain.) If they don't have a plugin for your host, you could look at moving the zone (e.g., CloudFlare is free for something like this, Route53 is <$1/mo) or finding another tool that does support it[1].

No external IPs involved anywhere and you can get valid, trusted SSL certificates for your domain. Set up the auto-renewal (in essentially all cases, add something to crontab), and it'll periodically dump new certificates to disk for you so you never need to think about the certificates again.

If you don't even want anyone to know that there's a "imap.mmd45.com" in existence _somewhere_ in the world, you can issue a certificate for `*.mmd45.com` and it will cover any direct subdomains.

Now you actually need to _connect_ to your mailserver with some sort of hostname rather than IP. For desktop devices and stuff, you could just throw this in /etc/hosts if you wanted. Some VPN/VPN-adjacent tools have ways to push mappings like that. Basically all of them have a way to override the DNS server in use if you were willing to run your own DNS server on the same host that has your mailserver. You can also just create a public record mapping imap.mmd45.com to 10.1.2.3.

[0] https://eff-certbot.readthedocs.io/en/latest/ [1] https://letsencrypt.org/docs/client-options/

If so, then you might want to mint your own root certificate and then import it to your iPhone.

ACME DNS-01 Challenge doesn't need a public resolvable and reachable host, it just sets a temporary DNS record to verify.

That adds a lot of attack surface vs. issuing a self-signed cert and confirming it was securely verified by your imap client.

Not only could let’s encrypt issue a mitm cert for your imap connections, so could other CAs, and any cloud providers / dns providers you use.

Uh what is a mitm cert? You're the custodian of the private key associated with the certificate, not LetsEncrypt.

And any CA can generate a certificate to MITM anything. That's why it's pretty much a requirement to submit all certs issued to Certificate Transparency, and if you're found to be misbehaving expect to receive ire from CA/B.

why should I require some third party's permission to do encryption between one of my computers and another one of my computers?

Because you chose to use a program that doesn't accept self-signed certificates. Use a different program or a different computer that actually respects your freedom to tinker with it. Problem solved.

No. He noted that it's a REGRESSION. So he chose one that DID accept them.

Running away from defects doesn't get them fixed.

Self-signed certs were a defect — people were used to just click OK and blackhats exploited that.

OP wants support for the special case where only the cert issuer trusts the cert (he has his own self-signed cert). Apple and others do support that: You make a private CA, trust that CA in the device, and then use that CA to sign certs for your IMAP server. IIRC (and this is from vague memory) you may need to configure yourself to be a company that manages employees' devices.

Interesting. I use self-signed certs for development, but haven't tried to use them for an E-mail server. After an article or two on here, I'm convinced that trying to run your own server is a futile time-suck.

It's not being required. just that the thread is about Let's Encrypt which ostensibly easier than setting up your own CA and distributing the root certificates to your devices. Which isn't too difficult but given how many people apparently use self-signed certificates, it's a bit high a bar.

The whole system and everything built on it that underlies trust in encryption on the modern Internet is designed in a way that requires parties called certificate authorities. That's just the design, since it was largely designed for two unrelated people to establish secure communication.

Clearly, it is not required to use a third party. First of all, you can sign your own cert using itself, then verify it manually. However, this is not the trust model that most Internet software uses. That model is closer to what SSH does, sometimes called TOFU (Trust On First Use). The model that is intended is for the certificate chain to be verified back to a trust root (ignoring other wrinkles.) There's really no particular reason why self-signed certificates must be supported.

Note that I don't think this makes the bug report invalid. It seems like a regression that is not intentional. However, the important point is that a third party still isn't needed to use the system as intended. You can, in fact, issue your own CA certificates, trust them on your devices, and then use those to sign your own certificates, making yourself the authority. This will work even on iOS as far as I know, and it follows the typical trust model so software should handle it as expected (though apps that use certificate pinning or bundle the Mozilla CA certificates statically instead of using the operating system's trust store may not work, but by and large it works.)

Personally, I just use Let's Encrypt. That way other people can establish a "secure" connection to my devices, too.

You shouldn't, and (this iOS bug aside) you don't, in general. But you're going to run into less friction if you do it the "blessed" way. That's just life.

There are many other questions to ask until you come to this question. One of them is; why iOS doesn't let me play my own mp3s?

You can, you just have to use iTunes from your computer like it’s 2003 to add it to your music library.

> Uh what is a mitm cert? You're the custodian of the private key associated with the certificate, not LetsEncrypt.

Don’t be obtuse. Letsencrypt and every other trusted CA has the ability to issue new certs for any domain at any time without you knowing.

There is absolutely no requirement to submit these to Certificate Transparency. That’s a thing some browsers do, but not most mail clients.

If you don’t trust the root CAs at all and only trust your self signed cert or only trust another signing cert you control, then a mitm isn’t possible without getting your private signing cert keys.

> Don’t be obtuse. Letsencrypt and every other trusted CA has the ability to issue new certs for any domain at any time without you knowing.

You shouldn't use words you don't understand. I already pointed this out.

> There is absolutely no requirement to submit these to Certificate Transparency. That’s a thing some browsers do, but not most mail clients.

If you want to be in Chrome bundle or Safari/Mac bundle you need to submit to at least one approved CT log. If you're found misbehaving or issuing non compliant certificates, expect ire from CA/B and potential ejection from certificate trust stores. This has happened quite a number of times, and CAs in the WebPKI trust are highly unlikely to issue a MITM certificate.

Not that it removes you entirely from the PKI ecosystem as you seem to desire, but in case you’re not aware since 2017 CAs are required to check and honour the CAA DNS records you set. These specify which CAs are allowed to issue certificates for your domain.

If any CA issues a certificate anyway, they’re in violation of requirement 3.2.2.8. Don’t know what you’re up to, but I have to imagine it would have to be pretty interesting to someone for one of those companies to face down an existential threat and misissue a certificate for your domain.

Pretty sure most people's threat model doesn't really care about the scenarios you mention. And for most people, that's fine.

A threat model which people using self-signed certificates especially care about.

The idea of certificate authorities, certificate chains and intermediary certificates is common - and based on top down security. That is the reason why it is so dangerous. There is a “lock” and people believe everything is “good” but actually DigiNotar, TurkTrust or the bad government issued a certificate. Google tried more than once to improve the situation but I think they just told Chrome only to accept their actual certificates for their services?

Messenger apps like Signal show how it should be done, the user itself checks and accept. Cameras and QR-codes made it easy. SSHs ASCII fingerprints are a nice thing, too.

PS: Yep. You shall look at the fingerprint of your chat partners in any messenger app.

why use a self signed certificate, why not create your own signer cert install that into IOS and then its no longer a "self signed" cert, but just a private cert org.

IOS does allow you to install private signer certs, right? (right?)

The rest of the world considers it self signed A standalone CA is great for everyone that can get manually trust it.

An employer installed one on my then-phone, so it should be within reach of the kind of tech who deals with self-signed certs.

There are or were two kinds of people using self-signed certificates. The vast majority used to be "I don't know how or can't afford to get a certificate chain cert."

Now, with letsencrypt, what's left of the "can't afford group" is "I can't be arsed to update my config yet".

Just because many people using self-signed certs are at the "don't know" stage isn't a reason to invalidate them.

For IMAP, I'm one of them! :-D

I love how the entire free PKI ecosystem is now relying on one single company.

It’s not. There’s LetsEncrypt, ZeroSSL, BuyPass, SSL.com, and Google Trust Services[0]. The ACME protocol is standardized and you can point your client at any of these at any time, and other providers can begin providing certificates at any time. Some tooling[1] even uses other providers by default.

[0] https://acmeclients.com/certificate-authorities/ [1] https://github.com/acmesh-official/acme.sh/wiki/Change-defau...

But if you distrust the entire PKI ecosystem, how are you intending to use your email server?

If someone is trying to send you an email, their admin definitely isn't going to set up an in-person meeting with you to exchange certificate signatures. Their server is either going to accept any certificate (which means MitM is trivial), or they're going to verify it against PKI (which you don't use because you don't trust it) and abort the connection upon seeing a self-signed certificate.

It's the same if you're sending a reply back: if you're not willing to trust PKI, your server has no way of verifying the recipient's server's identity. You don't trust PKI, and they are not going to manually exchange signatures, so your options are either not sending email at all, or accepting that it is MitMed.

So you're left with a threat model where your adversary is able to fake PKI certificates (so they are nation-state sized) and they are able to MitM the connection from your server to your client - but they are not able to MitM the connection from your server to a third party's server. Call me naive, but I highly doubt such an attacker exists.

The answer to this is that anyone that’s thinking in this way is already so elbow deep in security fetishism that real-world implications have long stopped mattering.

IMAP is for reading your emails not sending, that means you could accept PKI for SMTP to communicate with untrustworthy clients, but want to ensure that your access to your emails are safe(r).

Of course, but all emails you could read have been sent at one point or another. Unless you only care about local email delivery, you're going to have to get involved with PKI.

And if your threat model is bad enough that PKI isn't good enough for IMAP, why aren't you using a VPN in the first place? Or even an airgapped network? Or PGP?

iOS never supported this configuration regardless, a change in SSL certificate does not cause any kind of notification to the user.

Also, you're basically objecting to the entire idea of PKI for use in IMAP which is incredibly hard to justify. Perhaps you wish to use a different model for your own personal reasons but the default being PKI should not be controversial, and if you want to use your own model you should use a different mail client.

It did support it. One had to trust the certificate manually. I gave up on self-signed cents about 6 years ago.

It supported using self signed certs, but if the server suddenly switched from a self signed to a trusted CA-signed certificate, no prompt would be given. So the idea that self signed certificates are somehow more secure for this specific purpose is incorrect.

It was a complex Trust relationship and Apple’s it just work was onerous to work around. When security is the top priority I would alway go with self-signed certificates.

How does a self signed cert protect you from MITm if the iPhone will accept any signed certificate thereafter? There’s no cert pinning AFAIK in imaps.

You'd have to manually trust the MITM cert again? Which you certainly would not do as you know you didn't create a new self-signed cert in that moment.

https://letsencrypt.org/docs/caa/

Not enough? Account binding.

https://community.letsencrypt.org/t/enabling-acme-caa-accoun...

I wish they could break Snapchat, Facebook etcs ‘s self-signed certs. I own the device, why can’t I see the traffic to and from all of these apps if I add my self-signed cert and approve to use a MITM-proxy.

Most apps work, but not everyone.

Often called certificate pinning.

Apple isn't doing certificate pinning, it's the apps verifying the certificate chain themselves by baking in public keys (or hashes/fingerprints). So there's not really a way for Apple to break this.

Apple could say "If you wanna talk HTTPS, you have to use our HTTPSClient class, and that only supports using the system certificate store and does not support pinning".

Or they could say "All apps that don't support custom certificates for https will be denied app store approval".

While you're at it, make sure to have them prohibit any encryption on top of HTTPS, or apps might just be hiding things in application-level encryption schemes!

Banning certificate pinning... Do we really need mandated insecurity by prohibiting apps from doing better than trusting all Apple-trusted CAs around the world?

A better rule might be "You must use our HTTPSClient class, and it either uses the system+user trust stores, or optionally it uses an application supplied certificate authority+the user trust store".

They already do that to some extent, actually. Not as you mention, but because of US export compliance laws.

Countless encrypted messenger apps, GPG implementations etc. beg to differ.

Beg

Or you could ignore the self-signed aspect altogether, and instead give the OS VPN framework (where all network introspection stuff lives on iOS) a hook into the forced-choice HTTPS client — a hook that allows the active system VPN to say either “show me that before you encrypt it / after you decrypt it” or “don’t bother encrypting/decrypting that; I’ll handle it.”

Where, in the latter case, the TLS establishment is opaque, but then the VPN is handed the data that would be going through the TLS logic, plus an (also-opaque) handle to the established TLS-session RSA key, that it can use to finish the encryption/decryption process of each stream-chunk on behalf of the app, after doing whatever filtering / transformation / etc. it wants to do.

(Anyone remember Privoxy, the “MITM that works for you” that presaged most of the in-client features of Tor Browser? Same idea; just now with OS support.)

Why they would do that? They can't care less about what end user want, particularly in context we are discussing

The only way to "not support pinning" is to prevent apps from inspecting the certificate chain. This will break much more than pinning.

Can you not extract the key from the apps? They are only signed against modification, surely? Can you not read the data they have stored on the handset?

Generally apps like Fiddler generate their own cert which you load onto the device and accept. My understanding is this allows it intercept and re-write requests. When you do this, apps using cert. pinning will sniff out your "wrong" cert. and stop working.

No, the idea is that the app has the server's public key embedded in them, and they use that to verify that they're connecting only to the server with the corresponding private key.

Actually it depends. Apple does provide a way to configure your app for certificate pinning, which then allows you to pin certificates without any changes in your code. [1]

Any apps that set up certificate pinning this way could be bypassed by Apple, though obviously there would be little value in them doing it since that'd just lead to app developers doing what you're describing instead.

Though if I'm understanding this correctly, jailbroken phones could probably bypass it by modifying an app's Info.plist and running the app despite the broken signature.

[1] https://developer.apple.com/news/?id=g9ejcf8y

i saw a video on youtube where a guy intercepted https app traffic from an android app for a smart scale where the app used certificate pinning. there was some very automated tool for defeating the cert pinning. unfortunately i can't find the video link.

Probably objection, which uses Frida internally. Unfortunately, it depends on the implementation. It patches Java X509 classes, but some apps don’t use that.

The biggest pain is Flutter apps, which come with their own native TLS stack.

If you jailbreak your phone then you are able to remove certificate pinning. If you just want to do this for research purposes then you can buy an old iPhone6s, iPhone8 or iPhoneX and use checkra1n which uses a bug early in the bootchain in order to jailbreak the phone. I think palera1n is based on checkra1n and might have better support for newer iOS versions: https://palera.in/

No need to jailbreak to remove pinning; you just need to patch the app itself (for example, by replacing the certificate it verifies against or the code that does the verification).

you need some way to decrypt the app store app so you know what you are modifying and so you can resign which usually involves a jailbreak. maybe there are these apps that only have the first page encrypted so potentially you don't need to decrypt these apps because you can guess what the first page is.

Ownership philosophy aside, it's funny that you pick those two companies as examples.

The former enabled cert pinning (partially) as a response to a MITM[1] from the latter.

[1]: https://arstechnica.com/tech-policy/2024/03/facebook-secretl...

I run my own CA and install it as a trusted CA via Configuration Profiles. This works fine, including iOS 17.

Does this break in iOS 18 or does this affect only self-signed (untrusted) certificates?

I have the same setup and it works fine on iOS 18.

I feel like this going to happen to the permissionless side of crypto assets just like whats happened to most of the web 1.0 stuff

Walled garden things will take over and something is going to happen to EOAs that make them nerfed or rare

but at the same time, that might take 40 years just like these web 1.0 problems so its fine for now

I had this issue with let's encrypt certificates. IMHO it's unreleated to the issue. IOS18 mail initially connected using TLSv1.3. Afer deleting and re-installing Mail, the connection falls back to TLSSv1.2 and another set of ciphers. Then downloading of mails works again.

Using dovecot 2.3/Ubuntu on the server.

I think I've seen this before, in previous versions of iOS. You used to be able to just force a trust, but it would ask you again sometimes. I ended up just using LetsEncrypt certs, the one I use on the main website. Then I have a hook that also copies it to mailu.

tangent, but you can’t send mail on ios with an idn because “the sender address was invalid”, despite it working in macos. i’ve read this is caused by a broken regex check. if any apple employees are reading please take a look

There are so many quirks between the way Mail behaves on iOS vs Mac, its infuriating. At the core of it, if you are manually adding IMAP/SMTP/POP, both just need to get out of the way and stop trying to help. Very typical of Apple to think it knows better than you.

Does some other software (like the MUA) need to convert the IDN to punycode before submitting it to the OS?

Can you add your own CA cert to your device?

Yes.

Yes, I have a private CA I install on all my Apple devices for my self-signed certs. After I have the root CA on the device, it looks like any other valid SSL to iOS / macOS.

Nit-pick: In that case the certs aren’t self-signed, they are regular leaf certs, chained to a “non-standard” CA.

This is true, the user I replied to was asking about root CA's so I tried to address that.

At least with Safari all my internal SSL web services work properly on iOS with the root cert installed. Not sure about IMAP.

You can, but I find that much less secure than being able to TOFU a self-signed certificate:

I once did this, and besides being incredibly unergonomic, now I have to either securely destroy or safely store the signing key for the self-signed CA, or risk malware from performing an MITM against any app on my device, and not just e.g. the email client.

does iphone support name constraints on CA certificates? (https://systemoverlord.com/2020/06/14/private-ca-with-x-509-...)

I use letsencrypt for my mail server and I have done so for years, but iOS 18 appears to have broken my configuration which has worked perfectly for as long as I can remember. I believe my certificates were all set up correctly because it never gave me a problem up until now and never asked for authorisation of any kind. At this stage MacOSX works just fine, but iOS 18 and iPadOS 18 just do nothing.

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.

explain how a pinned self signed cert is insecure. i don't see it. it would seem to be more secure than one signed by a public CA that's not pinned.

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

Lazy

for the use case of a single user IMAP server this is all way, way, too complicated and buys you nothing in terms of security. it's completely analogous to why we dont use CAs to validate openssh host certificates.

Yes it's a analogous using CA is still a higher bar, but it would arguably be better to also use CA to validate openssh host certificates for all the reasons he listed above.

So maybe we should ask ourselves why can't we just figure out a way to improve handling of CA? Thanks to Let's Encrypt https coverage dramatically improved, now is maybe the time for more people to switch to self CA.

I agree though that promoting adoption through good tooling and pedagogy would be a nicer approach than Apple slap on the wrist.

You need to calm down and take a step back to realize not everyone needs to support 20 devices or even 2. What you’ve suggested is a ridiculous blanket statement assuming everyone is setting up things for a fleet of clients.

It really only is for bad practical reasons, that all coincidentally make it harder and harder to self-host stuff locally without paying a few dollars a month or year here and there to various rent seekers.

"Just use Letsencrypt" really is the correct answer for 99% of use cases, but good luck if you find yourself with one from the 1%. You'll get an army of people mindlessly parroting "best practices" and will assume you're incompetent/lazy if you can't find a way to make them work for you.

Internal CAs and self signed certificates are different. You can still generate a CA, sign your certificates, import your own CA into your phone and have that verify your certificates. You don't need Letsencrypt. But you'll learn in time.

Thanks for the condescension, but I know how to do all of this. I've done it before. And because of that, I can first hand attest that it's way too complicated.

No non-sophisticated user is able to run their own local CA, and that's why their NAS, IoT setup etc. all run over HTTP only, which in turn has implications for available web APIs (thanks to "secure origin only" policies and no exemption for local IPs/zeroconf domains) and many other things.

It also doesn't work for at least modern Android apps, since Android no longer makes user-provided CA certificates available to (non-browser) apps anymore, I believe, unless they're compiled with a special debugging parameter. On iOS it's still possible, but I'm not sure how long it's going to stay that way.

If a user set up a NAS they should be capable of googling

"Openssl how to set up a CA" > First link fully explains it https://arminreiter.com/2022/01/create-your-own-certificate-...

"How to import CA into iPhone" > First link fully explains it https://www.ibm.com/docs/en/mpf/7.1.0?topic=certificates-ins...

"Android app customize trusted CAs" > First link fully explains it https://developer.android.com/privacy-and-security/security-...

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

Setting up a NAS means buying one on Amazon and plugging it in.

You're completely out of touch with the majority of the userbase of these products if you think even one in 10 NAS users will set up their own CA using OpenSSL (in a secure way that doesn't expose themselves to being MITMed even on public sites such as that of their bank down the road).

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.

My point is precisely that current browsers and OSes make it impossible to ship a secure-by-default device running a local web server, NAS or otherwise.

Requiring users to install a globally trusted CA is a disaster from a security point of view (now my NAS vendor or anyone that hacks them can pose as google.com!), and for this reason doesn’t even work with modern Android apps anymore, for example.

Offering a layperson NAS buyer a self-signed cert is not "secure by default" even if browsers did accept it.

Would it be less secure than unencrypted HTTP?

No.

But if you want "secure by default" then neither one is acceptable.

How? An internal CA is just a self-signed certificate that you’ve told your device to trust; and to trust other certificates signed by it.

Somewhere you still need to trust a self-signed certificate.

You can guard the root certificate better than the leaf certificate. For example, you can keep it offline in an air-gapped environment.

There is no security hole if I am singing my own certificate for my own mails on my own server; it would mean that I do not trust... myself?

Now if I were to provide this as a commercial service, sure, my customers may be worried.

"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

>"This is good enough because I don't expect anyone other than me will use it" is lazy

is both a mischaracterisation of the argument, and wrong. It's not lazy, it's a choice with pros and cons. Just because you don't like it does not mean it is lazy. Again, issuing your own certificates is a choice.

Allowing self signed certificates does not "significant lower the bar". Did you know that all root certificates are self signed?

The management of multiple trusted certificates is basic administration for large private networks. Yes, TLS and certificate management can be complex, but that is not a good argument for disallowing it, and the idea that managing your own certificate trust is against "best practices" is ludicrous.

> Most people would click trust and get MITM'ed

So accept self signed on first connection with a detailed panel showing the certificate fingerprint. Then after that require a more involved process to accept a new certificate.

> do you really maintain every certificate both on it's application and on everything which needs to connect to it?

These are client certificates, and in some cases, they're actually pretty awesome.

> than signing all your PKI with an internal CA

That's a single layer of abstraction away from a self signed certificate, because, your CA _is_ a self signed certificate in this scenario. You've taken any defense in depth and thrown it right out the window.

The purpose of software is to make things possible not enforce random pedantry.

It's not that you're trusting your own certificate, it's that you're trusting any self-signed certificate, leaving you open to getting MITM'ed.

Can't you install trusted certificates by hand on iOS?

Yes, and you still can. That's not broken.

Based on the bug report I think it is. Mail is not respecting the self signed certificate that’s been added to the user trust store.

Why would this oblige the client to trust any self-signed cert as opposed to trusting all certificates whose chain of trust can be established using the system's trust store? The reporter isn't asking for mail to automatically trust untrusted certificates, they have added them to the trust store.

How? You add your signed cert explicitly to the trust store. You’re not just hitting “trust” every time.

Please keep in mind that a self-signed certificate is quite different from a certificate that is signed using a private CA.

The self-signed certificate has no link to a trust anchor. So it’s easy for Mallory to replace it with her own malicious certificate. It’s much harder for Mallory to replace a certificate that is tied to a CA.

Or is operating a local-only mailserver not connected to the larger internet? I guess that's a lazy or stupid thing too, these days...

I'm a fan of having TLS on by default for everything on the Internet, but I'm seriously annoyed by the collateral damage to local self-hosted services the implementation of that has caused.

It shouldn't be this hard to e.g. host web server on my local network that browsers grace with "trusted website APIs", but it really is. Why on earth do I need to set up Letsencrypt (and by extension at least DNS) on a local website if I want to be able to use a game pad on it, for example!? https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

We absolutely need a localhost and local domain exemption for both TLS/X.509 certificate validation and web APIs. For example, TOFU seems like a much better model for that use case than trying to bend the "public Internet" model until it fits. SSH has had considerable success in that model, for example.

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

Any malicious website can access my gamepad, since it can trivially get a Letsencrypt certificate – the only requirement for getting "secure origin" API access.

What exactly is this restriction preventing me from, then? (And what does a malicious website do with my gamepad data anyway?)

> Not never, but the total amount of users doing it is probably high tens or low hundreds at most

Yes, I'm fully aware that local hosting is rare in the grand scheme of things, but I think you're vastly underestimating the potential. It's currently not even possible to do much better even as a commercial NAS provider, and these are somewhat popular.

A big part of that also seems like a chicken and egg problem: Fewer and fewer users do it because it's getting harder and harder, thanks to browser standards and OS defaults being largely driven by stakeholders that have no interest in it becoming easier.

Yes, none of this is an evil conspiracy; it's just a question of incentives and priorities in the end. I just find it so sad how willingly even a "hacker" audience here embraces the move towards more and more centralization, on more than one dimension. (Peer-to-peer vs. client-to-server, "trusted CA only" vs. trust on first use, cloud vs. self-hosting etc.)

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

Then only allow self-signed certificates for literal IPs or those on .local (and other private/reserved TLDs).

Right now, .local is completely impossible to encrypt, as well as impossible to use “secure origin” APIs on, which is a shame.

.local also hasn't been best practice since 2005. Current recommendation, because of Certificates is to use internal only subdomain of domain you have control over.

What? .local is the dedicated TLD for Zeroconf/Bonjour/mDNS! How is that deprecated?

And you’re just reconfirming my point: All of these recommendations are great for publicly hosted sites or corporate environments, but largely impracticable for home users that don’t know how to, or don’t want to, have a second job as sysadmins.

Home users also don't have IMAP servers they run themselves. They are in public email service.

I don't think it's crazy for a NAS to provide an IMAP server, e.g. to backup or archive a large mailbox.

One of the selling points of a NAS is that storage is much cheaper than what the large cloud providers charge per GB and month.

Cool, you don't but obviously you don't deal with a ton of normal users. They are not running NASes, they will just toss Google some cash for bigger GMail box.

> We absolutely need a localhost and local domain exemption for both TLS/X.509 certificate validation and web APIs.

localhost is already considered a secure origin.

Local networks are horribly insecure; easily the most likely place for a MITM attack.

Ah, that’s good – it’s been a while since I last had to work around that.

And I generally agree on local networks being insecure. So how about making them more secure instead of marginalizing them even more?

TOFU for TLS certs on .local (for Zeroconf, and maybe something else/new for local DNS) would be a huge step forward from unencrypted and unauthenticated HTTP. Such sites could even still be displayed with a broken padlock or whatever HTTP gets these days to not create any false expectations by users.

It’s 2024, we’ve seen countless examples of sophisticated hackers getting into all kinds of systems. Anybody who makes a blanket statement that you have to trust the public PKI is either lazy or stupid.

SSH has TOFU and it works very well if you don’t want a key infrastructure.

Does anyone know if there is any way to get iOS's mail client to present a client cert? Or, barring that, any form of self-hosted MFA.

:-(

hey lurking apple devs- can someone please escalate this?

I would not bet money that Apple is willing to change their mind regarding this question.

per apple dev forums it seems like they have a history of breaking this and then fixing it. additionally, while IMAP is broken, calendars and notes seem to work just fine so hopefully it's not deliberate.

And the Apple fanboys are loose again...

Regardless how your opinion on PKI and self-signed certificates is, shouldn't we at least be bothered by the fact that Apple just switched off this feature without any communication whatsoever? The community was literally in the dark about whether this is an official policy change or a bug.

Google, in situations like this, at least made some corpospeak press release officially "sunsetting" the feature and provided an official deprecation timeline so users have time to adapt.

Apple is apparently just leaving their users stranded and unable to access their email.

I suspect it's worse than that.

Since the UK's Investigatory Powers Act 2016, I've noted that every web browser is necessarily an end-to-end encrypted communication system.

This isn't compatible with what all the spy agencies want. The US can kinda get past that with the reporting obligation for anyone publishing on an app store controlled by a US company. (As a British citizen living in Berlin, the corresponding checkbox when publishing apps is mildly infuriating).

Now that Apple is obligated to allow competitors, that doesn't work. Or perhaps the agencies finally noticed that this problem applies to websites and not just apps (perhaps web apps are finally good enough?)

So the agencies find another way — and this time it comes with an obligation to not report what they're doing.

This smells like that other way.

Might not be correct, but intelligence agencies' long-standing history means it's not paranoia.

https://developer.apple.com/forums/thread/732409 (fixed url)

seems like the issue is specifically with IMAP- I can confirm that calendar syncing works fine with the self signed cert.

this is really disappointing.

So in summary: iOS used to accept untrusted certificates, yikes! Now, it validates the server cert, and people are upset? This blatantly insecure thing is broken now and the posters don't want to set it up securely?

It seems like these people are just struggling with how to properly set up their email server and clients when using a private CA. If you're going to use your own CA, then configure your client to trust it. The rest of us should be able to enjoy secure defaults and not have to worry about our less informed family members being tricked into bypassing basic security protections like TLS validation.

bad summary. it prompted you to accept the certificate upon first use and then pinned it which is far different than what you are describing in terms of security implications.

TOFU for invalid/untrusted certificates is the equivalent of "go there anyway" in a browser Very different than explicitly trusting a Private CA. It means that skilled attackers can rely on unskilled users clicking the "trust me, it's fine" button. All so that someone skilled enough to set up their own email server and certificates doesn't have to configure their system securely?

This is about making bad things harder for unskilled users at the cost of raising the standard for service providers. If you can set up an email server, you can use easyrsa or step-ca or some manual openssl to create your own root CA. Or, register your self-signed email server as a trusted root CA.

Personally, I use easyrsa for my internal CA (with domain path constraints because I'm paranoid) and letsencrypt for my mail server, but I require VPN access to the user ports on the mail server.

you are assuming i have users and this is a mail server not a website which has a very different access pattern more analogous to ssh where TOFU works beautifully.

Reply on news.ycombinator.com