The good news is that Microsoft's next Patch Tuesday, due on September 11, should be a breeze, bringing just two security updates. The bad news is that October's Patch Tuesday will be a game changer, and Microsoft has cautioned Windows admins to take advantage of the lull to make sure their security houses are in order. …
Shouldn't be much of an issue...
Simply because most SSL key providers (GoDaddy being my main example) have been enforcing a minimum key length of 1024 for years now.
I think the only situations which could be affected is when people generated a self-signed certificate simply because of the ease and not so much of the security aspects.
Re: Shouldn't be much of an issue...
That's exactly what's going to happen -- internal corporate web apps are going to break, not major online services.
It's been my experience as a system admin that many of my fellow admins consider public key cryptography a black art. It's not hard to understand once you have a few app deployments under your belt, but wow. I've seen a lot of apps used internally where it's pretty obvious that someone just went through an online walkthrough to set the SSL certs up, then ran FAR away from it once they got the webpage to display without an error message.
So yeah, I can see a lot of people running into this, especially since AD lets you import self-signed certs. And it's going to confuse a lot of people until they hit Google the next day and see the "help me, I'm over my head" forums like ExpertsExchange and the like fill up with "OMG - No one can access our internal LOB application, PLEASE HELP URGENTLY".
"It's been my experience as a system admin that many of my fellow admins consider public key cryptography a black art."
And yet you claim those would still (consider to) use self-signed certificates (a /lot/ more work) instead of simply applying for one at a regular SSL provider? I consider that to be quite unlikely.
Because most fellow admins I came across (the kind of people you mention here; who apparently don't quite see that the SSL structure is in the end a simple form of public key encryption) wouldn't trust a self signed certificate over that from a recognized SSL provider. Because you know; those are the official certificates, and thus much safer.
Sorry, but your story doesn't quite add up for me.
And you seem to entirely miss the fact that self signed are free and companies dont like to spend money on certs if they can avoid it. Most https sites internall are https because someone mandated they should be, but almost certainly wont pay for a proper cert.
Given a lot of apps have a 'or use a self signed cert' option on install that it will generate it on demand I would say that is a lot less effort than a CSR and a cert signing company?
Self-signed certificates *are* less secure than "official" ones. They require you to understand the implications of a certificate that anyone can create to say whatever they would like and create a suitable out-of-band mechanism for getting the certificate onto client machines. I've lost count of the number of "secure" websites I've seen that are anything but, because the end users have become accustomed to seeing cert errors on them and simply installing which one the browser says they need to make the errors stop, after all it has the company name in it, so it must be safe, right?
Exactly, self-certs are mainly about saving money.
Get over yourself. Lots of systems chuck out a self signed certificates by default and there are plenty of next-next-next jockeys who will accept that. Exchange 2010 for example.
don't forget government agencies where deploying a self-signed cert avoids lengthy approval processes for stuff "nobody outside of our group will ever need."
2048 minimum for Namecheap, I believe. I'm not worried; and it's about time the vintage certs got flushed or upgraded. Pain in the arse if you are in charge of a lot of legacy stuff, of course.
When they say IE will block sites using wads too short, will that be a popup that specifically says why, and allows you to click through and harass the admins later, after you've gotten your work done? I'd hate for MS to target the tardy, and end up forcing people to use other browsers. Oh yes indeedy, I'd hate that...
Re: IE blockage
Almost certainly, that's what it does now when presented with a moody cert.
It'll bitch, but it'll happily let you go to hell in a bucket if you ignore the security warnings and messages of impending doom.
would it not have been an idea to force a patch 6 months ago which just popped up a warning but allowed the user to proceed, before issuing another patch to outright block?
Not everyone might have the ability to get legacy code re-signed.
Honestly, I think that would only delay deployment until they issue the hard block. All it would gain them would be the satisfaction of saying "we gave you six months of on-screen warnings that your certs needed to be fixed," but in a certain sense, they've already been warning for a year.
We support systems for local authorities and we cant even get 1024 certificates anymore, everyone is insisting on 2048 and have been for about a year now.
I am pretty sure all self signed certificates default to 1024 too, or at least the example in selfssl.exe shows 1024. The IT that gets caught out by this are probably gonna be pretty crap
Re:"everyone is insisting on 2048 and have been for about a year now."
Yep. The IT dept here at Uni starting tackling that issue a good while ago. It is also clear from the article that this should not come as any surprise to anyone - it's not exactly been sprung on them at short notice.
A minor correction
It may be that experts are advising increasing RSA lengths beyond 1024 bits, but the link in the article was to a piece about generation of RSA moduli with poor random number generation schemes, specificity those which result in a small number of possible primes. These schemes offer no more security at 2048 bits as they do at 1024.
I would hope there would be some registry option or whatever for those who are utterly unprepared. That said, *shrug*, I was already over-riding ssh (of old's) default 1024-bit keylength like 15 years ago, using 2048-bit keys instead. Back then, the 16-mhz boxes (or so) that I had would actually take extra few seconds at key-exchange time due to this. These days, there's really no reason not to use a long key length. Hopefully anyone unprepared won't go to a 1024-bit key -- remember, that is bare minimum these days.
There is an option for the utterly unprepared.
You don't approve the patch in WSUS.
There is no option for the utterly incompetent who don't keep things up to date, don't read the IT news, and haven't implemented WSUS.
Not sure this will cause too much of an issue
I know that the default for OpenSSL-created self-signed certs has been 1024 bits for years now, though there's always a chance someone created one on an intranet years ago with a 512 bits and a long expiry date I guess, but I suspect that's fairly rare.
As people have been saying, 1024 bits has been the minimum key size for years on paid SSL certs and in the last 1-2 years, there's been a switch to 2048 bits as the minimum for most SSL vendors (I know Symantec/Verisign and RapidSSL have insisted on 2048 bits for at least a year now).
I'm a bit surprised the article made no mention that the default/minimum has been at least 1024 bits for a long time now and 2048 bits recently for paid certs, so the impact of this change shouldn't be too great.
apache friends xampp
has had 1024bit ssl cert making for self signed certs for a long time....
Despite years of stories about illegal mass surveillance, and insightful articles covering the merits and pitfalls of SSL... remains insecure, with no encryption at all?
Re: The Reg?
....and El Reg needs to be secured because..............what exactly?
"Oh noes, some blackhat intercepted my cheesy post about rounded corners"......I can live with that.
Re: The Reg?
quote: "Despite years of stories about illegal mass surveillance, and insightful articles covering the merits and pitfalls of SSL... remains insecure, with no encryption at all?"
My company is in process of implementing a transparent MITM box to "virus scan" incoming SSL traffic alongside the unencrypted stuff along the company internet connection, so in my case it would make approximately fuck all difference in my exposure to possible surveillance; switching to HTTPS would just mean it's on the logs of another appliance. I am sure many multinationals already do this on their own networks, so I think the "security" of SSL should already be considered suspect for any corporate connection regardless of key length, and TBH I'd also consider it suspect on a home connection, as the certificate registries (i.e. the ones your OS / browser trusts by default) are already physically on the turf of one government or another. I don't actually trust any of them to not be already compromised in the name of national security (i.e. a government MITM box at the ISP, using certs signed by a cetificate registry that your browser implicitly trusts).
In my opinion, the Reg in clear text is as secure as it is ever going to get, regardless of the SSL technologies that could be implemented, and the same goes for every internet site ever pretty much. :)
Re: The Reg?
A case could be made that any website with password-protected accounts should use SSL, at least for the step where you actually send the password. Still, since the worst anyone could do with a stolen account is make an embarrassing post in my name, it's hardly a high value target.
Re: make an embarrassing post in my name
and in most cases, not actually your Name, but your Handle, like your Posting Name clearly indicates.
- Leaked screenshots show next Windows kernel to be a perfect 10
- Product round-up Coming clean: Ten cordless vacuum cleaners
- Something for the Weekend, Sir? I need a password to BRAKE? What? No! STOP! Aaaargh!
- Episode 13 BOFH: WHERE did this 'fax-enabled' printer UPGRADE come from?
- Vulture at the Wheel Ford's B-Max: Fiesta-based runaround that goes THUNK