Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iOS 18 breaks IMAPS self-signed certs

forums.developer.apple.com

Post reply on HN
Print view View original

81–90 of 157 posts

Re: iOS 18 breaks IMAPS self-signed certs

#81

Post by [deleted] »

stephenmac98 wrote: post #35
shakow wrote: post #19

Earlier quoted context omitted.

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 w…

[deleted]

Re: iOS 18 breaks IMAPS self-signed certs

#82

Post by denkmoon »

anamexis wrote: post #37
shakow wrote: post #19

Earlier quoted context omitted.

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.

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.

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.

Re: iOS 18 breaks IMAPS self-signed certs

#83

Post by stackskipton »

lxgr wrote: post #64
stephenmac98 wrote: post #61

Earlier quoted context omitted.

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 wit…

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.

Re: iOS 18 breaks IMAPS self-signed certs

#84

Post by denkmoon »

stephenmac98 wrote: post #35
shakow wrote: post #19

Earlier quoted context omitted.

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 w…

>"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.

Re: iOS 18 breaks IMAPS self-signed certs

#85

Post by akira2501 »

stephenmac98 wrote: post #35
shakow wrote: post #19

Earlier quoted context omitted.

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 w…

> 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.

Re: iOS 18 breaks IMAPS self-signed certs

#86

Post by beeflet »

commandersaki wrote: post #78
hedora wrote: post #74

Earlier quoted context omitted.

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?

Re: iOS 18 breaks IMAPS self-signed certs

#87

Post by Twisell »

mmd45 wrote: post #60
stephenmac98 wrote: post #45

Earlier quoted context omitted.

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 wil…

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.

Re: iOS 18 breaks IMAPS self-signed certs

#88

Post by kijin »

beeflet wrote: post #86
commandersaki wrote: post #78

Earlier quoted context omitted.

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.

Re: iOS 18 breaks IMAPS self-signed certs

#89

Post by fragmede »

beeflet wrote: post #86
commandersaki wrote: post #78

Earlier quoted context omitted.

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?

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.

Re: iOS 18 breaks IMAPS self-signed certs

#90

Post by nerdile »

mmd45 wrote: post #36
nerdile wrote: post #34

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 i…

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.

Post reply on HN