| ▲ | zephius 4 days ago |
| Old SysAdmin and InfoSec Admin perspective: Dev guys think everything is solvable via code, but hardware guys know this isn't true. Hardware is stuck in fixed lifecycles and firmware is not updated by the vendors unless it has to be. And in many cases updated poorly. No hardware I've ever come across that supports SSL\TLS (and most do nowadays) offers any automation capability in updating certs. In most cases, certs are manually - and painfully - updated with esoteric CLI cantrips that require dancing while chanting to some ancient I.T. God for mercy because the process is poorly (if at all) documented and often broken. No API call or middelware is going to solve that problem unless the manufacturer puts it in. In particular, load balancers are some of the worst at cert management, and remember that not everyone uses F5 - there are tons of other cheaper and popular alternatives most of which are atrocious at security configuration management. It's already painful enough to manage certs in an enterprise and this 47 day lifecycle is going to break things. Hardware vendors are simply incompetent and slow to adapt to security changes. And not everyone is 100% in the cloud - most enterprises are only partially in that pool. |
|
| ▲ | tptacek 4 days ago | parent | next [-] |
| I think everybody involved knows about the likelihood that things are going to break at enterprise shops with super-expensive commercial middleboxes. They just don't care anymore. We ran a PKI that cared deeply about the concerns of admins for a decade and a half, and it was a fiasco. The coders have taken over, and things are better. |
| |
| ▲ | zephius 4 days ago | parent [-] | | That's great for shops with Dev teams and in house developed platforms. Those shops are rare outside Silicon Valley and fortune 500s and not likely to increase beyond that. For the rest of us, we are at the mercy of off the shelf products and 3rd party platforms. | | |
| ▲ | tptacek 4 days ago | parent [-] | | I suggest you buy products from vendors who care about the modern WebPKI. I don't think the browser root programs are going to back down on this stuff. | | |
| ▲ | nickf 4 days ago | parent | next [-] | | This. Also, re-evaluate how many places you actually need public trust that the webPKI offers. So many times it isn't needed, and you make problems for yourself by assuming it does.
I have horror stories I can't fully disclose, but if you have closed networks of millions of devices where you control both the server side and the client side, relying on the same certificate I might use on my blog is not a sane idea. | |
| ▲ | whs 4 days ago | parent | prev | next [-] | | Agree. My company was cloud first, and when we built the new HQ buying Cisco gear and VMware (as they're the only stack several implementers are offering) it felt like we were sending the company 15 years backwards | |
| ▲ | zephius 4 days ago | parent | prev [-] | | I agree, and we try, however that is not a currently widely supported feature in the boring industry specific business software/hardware space. Maybe now it will be, so time will tell. | | |
| ▲ | ignaloidas 3 days ago | parent | next [-] | | Hey, you now have a specific cost to point to when arguing for/against solutions that have this problem. "each deployment will cost us at least 12 specialist hours per year just replacing the certificates" is a non-negligible cost that even the least tech-minded people will understand, and it can be a good lever for requiring the support. | |
| ▲ | ikiris 3 days ago | parent | prev [-] | | Reverse proxies exist. If you don’t like having to do that then have requirements for standards of the past 10 years in your purchasing. |
|
|
|
|
|
| ▲ | cpach 4 days ago | parent | prev | next [-] |
| “Hardware vendors are simply incompetent and slow to adapt to security changes.” Perhaps the new requirements will give them additional incentives. |
| |
| ▲ | zephius 4 days ago | parent [-] | | Yeah, just like TLS 1.2 support. Don't even get me started on how that fiasco is still going. |
|
|
| ▲ | yjftsjthsd-h 4 days ago | parent | prev | next [-] |
| Sounds like everything is solvable via code, and the hardware vendors just suck at it. |
| |
| ▲ | zephius 4 days ago | parent | next [-] | | In a nutshell, yes. From a security perspective, look at Fortinet as an egregious example of just how bad. Palo Alto also has some serious internal issues. | |
| ▲ | dijit 3 days ago | parent | prev [-] | | not really, a lot of those middleware boxes are doing some form of ASIC offloading for TLS, and the PROM that loads the cert(s) are not rated for heavy writes… thus writing is slow, blocking, and will wear your hardware out. The larger issue is actually our desire to deprecate cipher suites so rapidly though, those 2-3 year old ASICs that are functioning well become e-waste pretty quickly when even my blog gets a Qualys “D” rating after having an “A+” rating barely a year ago. How much time are we spending on this? The NSA is literally already in the walls. |
|
|
| ▲ | Havoc 3 days ago | parent | prev [-] |
| At the same time I don’t think it’s reasonable to make global cert decisions like this based on what some crappy manufacturer failed to implement in their firmware. The issue there is clearly the crap hardware (though the sysadmins that have to deal with it have my condolences) |
