Discussion in 'Business & Enterprise Computing' started by elvis, Jul 1, 2008.
Sounds like you both have a lot of fuckin passengers at your companies.
you catch even more flies with shit.
Or dead bodies.
Flies DO tend to preferentially hover around open mouths!
Sounds like your security team is filled with dickhead auditors rather than actual security folk who understand that security is a pragmatic mindset ('this is why we need this rule') rather than a set of controls ('TLS inspection stahps malwarz').
TBF if you don't SSL decrypt you're obviously blind to the contents aside from checking the SNI (enter TLS 1.3) and even that's just basically a 'is this a reputable site' tick which doesn't check the actual content
HSTS and TLS 1.3 works with SSL decryption with the right vendor/OS - but notably Palo Alto needs PANOS-10 and you're living on the edge if so, hence gubbermint says no (also current spec PAN boxes will melt but that's another story)
What breaks SSL decrypt is certificate pinning so yeah its whack a mole with that, but it has to be baked into the app/service. If you're standing up a new service you have to actively implement it. Its basically a bunch of SaaS stuff (notably Office365, some parts of messenger, snapchat etc). I obviously don't know your full context and technical details but there should not be a genuine technical reason stopping you aside from existing SSL decrypt config/infra/posture being wrong which isn't really your fault (but politically you may be snookered badly I get it)
If you don't do SSL decrypt then your shiny NGFW (assuming TLS 1.2 downgrade) is doing a great jerb at DNS filtering (SNI check) and thats basically it ROFL. If you're serious about security you need to get at the payload, otherwise even a simple HTTPS download from eicar will sail right through.
We've beat this horse before but I'll beat it again, yeah its futile and anybody decent runs away [starts getting PTSD at the memory]
Even facing into govt as a presales function is like pulling teeth, nevermind hobnobbing with the pricks in charge and the arcane specialist knowledge / contacts required to win
You could not pay me enough to take a govt job (aside from stupid money)
For this project, I'm not. It's public data, which gets processed in the public cloud using open source software packages in containers that are built by a CI/CD system also in the public cloud and auditable by the public, and then the results of all of that are made available to the public.
The actual need to go full retard on SSL inspection is non existent. It's not end user desktop crap. It's people pulling source and packages from PyPi/CRAN/GitHub. It's merely bureaucracy gone mad and a blatant disregard for the actual project requirements, security or otherwise.
It's also a guaranteed way of ensuring a very high visibility cloud project will fail, which I'm sure is the intention.
A very pro public service friend of mine convinced me to give this a go, telling me the bad rap government gets was all hyperbole and there were rewarding jobs around.
She then had a breakdown from her own public service job and quit, escaping to the private sector six months after I started.
All this has really done for me is reinforce so many of my preconceptions.
Maybe there's a twisted logic in that; the 'security' team can go 'look I did mah jerb enforcing policies I'm not a seatwarming oxygen thief like my other govt counterparts'
OK point taken, however, I guarantee you there is a way of getting it to work properly IF you're talking only about TLS 1.3 and HSTS (as opposed to HPKP i.e. pinning). Could be as 'simple' as virtual NGFWs that's configured properly (i.e. not by a chump). OFC with cloud networking it can get not so simple and now you're in a shared environment soooooo... (have lost track of the number of transit GW / transit VNET conversations I've had in the last 2 years)
Ingress / server SSL decryption is even easier and does not involve any of the whack-a-mole nightmares of decrypting client-side outbound - you simply import the web cert and away you go, though yes no more letsencrypt outside of your own scripts to certbot and API back onto the middlebot.
HOWEVER if its web facing server then the correct answer here is a WAF as its going to do a 10x better jerb and then you simply terminate HTTPS on the WAF which then merrily load balances. There's even cloud native ones and yep pay the provider for the privilege of auto rotating certs tied to the provider hosted DNS and associated goodies, huzzah.
I'm not entirely clear anyway whether they're forcing it on outbound or inbound. nvm
In any event leaving my security hat on, sure let them pull from ubuntu/pypi etc. merrily without inspection as long as there are further segmentation controls so if these gets hosed by someone planting malware on a 'good' update site you're not pantsdowned.
I'm sorry your friend told you lies
I'd love to give them the benefit of the doubt, I really would. But I remember talking to their boss 18 months ago and mentioning the word "containers", and watching him go very pale. Even paler 90 days later when I we met a second time, and I revealed I'd done what I wanted to do 90 days earlier, the containers were in and working and staff were shooting them in production, and he realised I wasn't here to shag spiders.
Their entire MO since has been to say "no" to everything.
I look forward to weeks and weeks of testing and feedback while they figure that out.
Well, silver lining, I learned it first hand for myself. Now I know.
thats basically how I viewed my stint in gubbermint. That and I levelled up a few technolgies like crazy, a few months of reverse engineering P1s daily (on stupid complex, stupidly designed and not-at-all-documented or monitored environments) will do that
The final result of this decade's challenge was that the API used was indeed fair use:
In reviewing that decision, we assume for argument's sake, that the material was copyrightable. But we hold that the copying here at issue nevertheless constituted a fair use. Hence, Google's copying did not violate the copyright law.
Since the ruling was made assuming that the material was copyrightable, it does not say whether or not it agreed with the decision that the API itself is copyrightable or not. However, it does rule that even if the API itself was copyrightable, then reimplementing that API is fair use, and so does not constitute a copyright infringement.
Held: Google's copying of the Java SE API, which included only those lines of code that were needed to allow programmers to put their accrued talents to work in a new and transformative program, was a fair use of that material as a matter of law.
Interesting result for public APIs, reimplementing a documented API is not an infringement and has no punitive damage.
yay, some common sense in use in the judicial system.
Courtesy of a squad of expert lawyers and an unlimited legal fund.
justice may be blind, but she ain't cheap.
When corporate users complain about speed then run speed tests and realize their corporate network is cutting download speed to one tenth of what it should be.
rate limiting them or are they on 100Mbps switches with a GB pipe?
Who cares, they shouldn't need Gb speeds all the time anyway - and if they often do, there's business budget to pay for it.
Well his complaint is a little broad. If they have a 50mb link and the business is rate limiting users to 5Mbps then thats very different to a speed test showing 100Mbps but business on GB
Sure, but it's more fun my way.