4 ms·
It must have been many many years ago, more than 10 at least. Any way to avoid or bypass name or path constraints would be considered a huge and monumental vul
by jitbug 7y ago
It must have been many many years ago, more than 10 at least.
Any way to avoid or bypass name or path constraints would be considered a huge and monumental vulnerability today.
- acdha 7y ago> It must have been many many years ago, more than 10 at least. You would be unduly optimistic — for example, Apple did not support them at least as recently as 2015 (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=407093#c2 https://bugs.chromium.org/p/chromium/issues/detail?id=407093...) and 10 years ago OpenSSL hadn't even shipped support upstream, plus however long it took your distribution to ship a major version upgrade to 1.0. I was hoping someone might have a pointer to current information on that topic since I believe Apple did finally fix Secure Transport but not when.
- gnyman 7y agoI am afraid I don't have better information on when but some anecdotal information about the state of it. I have done some limited testing and research for our own internal Root CA I got the impression it works nowadays. I have not gotten as far as testing it in production but based on testing Safari and Chrome in https://nameconstraints.bettertls.com/ https://nameconstraints.bettertls.com/ and creating our own name constrained cert and testing it with both OS X Curl and Linux Curl (OpenSSL) I am still of the impression it works. Most other people seem to be sure that it does not though (for example in this discussion and here https://security.stackexchange.com/questions/95600/are-x-509-nameconstraints-on-certificates-supported-on-os-x https://security.stackexchange.com/questions/95600/are-x-509...) so I am not sure if I missed something or if people are just not up to date.