SoylentNews is people
SoylentNews
from the honestly,-it's-for-your-own-good... dept.
Safari will, later this year, no longer accept new HTTPS certificates that expire more than 13 months from their creation date. That means websites using long-life SSL/TLS certs issued after the cut-off point will throw up privacy errors in Apple's browser.
The policy was unveiled by the iGiant at a Certification Authority Browser Forum (CA/Browser) meeting on Wednesday. Specifically, according to those present at the confab, from September 1, any new website cert valid for more than 398 days will not be trusted by the Safari browser and instead rejected. Older certs, issued prior to the deadline, are unaffected by this rule.
By implementing the policy in Safari, Apple will, by extension, enforce it on all iOS and macOS devices. This will put pressure on website admins and developers to make sure their certs meet Apple's requirements – or risk breaking pages on a billion-plus devices and computers.
[...] Shortening the lifespan of certificates does come with some drawbacks. It has been noted that by increasing the frequency of certificate replacements, Apple and others are also making life a little more complicated for site owners and businesses that have to manage the certificates and compliance.
"Companies need to look to automation to assist with certificate deployment, renewal, and lifecycle management to reduce human overhead and the risk of error as the frequency of certificate replacement increase," Callan told us.
We note Let's Encrypt issues free HTTPS certificates that expire after 90 days, and provides tools to automate renewals, so those will be just fine – and they are used all over the web now. El Reg's cert is a year-long affair so we'll be OK.
GitHub.com uses a two-year certificate, which would fall foul of Apple's rules though it was issued before the cut-off deadline. However, it is due to be renewed by June, so there's plenty of opportunity to sort that out. Apple's website has a year-long HTTPS cert that needs renewing in October.
Microsoft is an interesting one: its dot-com's cert is a two-year affair, which expires in October. If Redmond renews it for another two years, it'll trip up over Safari's policy.
(Score: 2) by barbara hudson on Wednesday February 26 2020, @01:52AM (3 children)
IP
UDP
TCP
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 0) by Anonymous Coward on Wednesday February 26 2020, @02:39AM (2 children)
No they don't. TCP and UDP are completely independent. TCP is in no way a stacked on top of a UDP datagram. If you knew anything about the way their respective headers looked or what the packets look like, you would realize that. UDP was designed to be TCP with a bunch of stuff ripped out that wasn't necessary for types of messages, such as DNS, that still needed ports unlike bare IP or other network protocols.
(Score: 2) by barbara hudson on Wednesday February 26 2020, @02:55AM (1 child)
The original IP/TCP implementation was wrong, so the IP layer was removed from the TCP layer. Today's TCP/IP is not the same as the original TCP/IP, same as today's Buick is not yur gramdpa's Buick. UDP and TCP both run atop IP. There's lots of code from UDP in TCP. In that sense, TCP is built upon UDP. Just because the packet headers are different is meaningless - how else would you distinguish them except by the headers?
Same as YModem shared lots from XModem, and ZModem shared lots of the same design with both. Serial communications hasn't really changed that much in 40 years if you dig enough.
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 0) by Anonymous Coward on Wednesday February 26 2020, @03:02AM
Your ability to miss the point is amazing. If TCP really were stacked on top of UDP, as you claim, just as the application layers are stacked above them and the internet layers below, then a TCP datagram would literally be a UDP datagram whose payload is a TCP datagram same as how an IP packet's payload is a transport layer datagram, and how the transport layer's payload is the higher level's headers and data. If I weren't convinced you were being obstinate on purpose, I'd suspect you were as mentally ill as your SN nemesis.