[HowTo Guide] How to force users to install CA root certificate to gain access
-
So, if I get this right:
"How to force users to install CA root certificate to gain access" boils down to a classic MITM !?!This is actually just fine if you really want to find out what your kids, or any other person you have authority over, are doing on the net.
But doing this with 'people' (actually strangers to you) that are looking for a internet access, this won't work.
I guess, when you explain them what you are doing, your portal adventure stops right there …. by lack of any interested users.
Not telling them, well, in most civilized states and countries, its a one way ticket to jail ;)If you really want to protect all these BYOD, just forbid https - accept http only, so users will know that the connection isn't 'save', that Uncle Sam (and his entire family) AND YOU are watching ..... ;)
-
Gertjan: It do work. Actually, in most countries, but not all, encrypted VS nonencrypted traffic is treated the same, eg if its illegal to scan HTTPS traffic, then its illegal to scan HTTP traffic, and vice versa.
For example, here there is only 1 law regarding scanning of traffic (regardless of encrypted or not), and that law does only apply to licensed ISPs which operate public mobile or wired large networks (a Wifi hotspot does not count to the license ISP requirement here in sweden unless it cover a very large area so the network essentially is no longer "local").This law applying to licensed ISPs and operators, actually means customers of prepaid mobile broadband, that uses a captive portal to "refill" the prepaid card, actually needs to consent to the captive portal first time they use the SIM card.
In all other cases, its legal to scan the traffic, as you own the equipment that the traffic pass. Logging however, regardless of cleartext or encrypted traffic, (access logs, virus logs etc) can be a legal problem in some cases (PII laws, or "PUL" as they are called here in sweden), but that is solved by having the user to consent to the logging by a agreement page.
And forbidding HTTPS can be a pretty large problem when almost every site is using HTTPS today.
But as I have clearly descirbed, this is not intended to "find out what people are doing on the internet", this what I wrote, is intended for:
**antivirus scanning and threat scan of encrypted traffic to block any threats from coming into the network.
Its designed to make the network more safe for all users to use, even if someone inside clicks on VideoPlayer.exe with UAC off.And to ensure that safety, you must make tradeoffs. Either let encrypted traffic pass unscanned, and then you have a virus threat, or scan the traffic, but then you need to make a MITM on the user instead.
Theres really no choice.**
-
Just out of curiosity: Where is "here"?
-
He mentions Sweden.
Yes, Derelict, if the user installs the CA, the squid server will become the CA of every website on the globe, regardless of which home page the user have set. BUT: That is only temporary while the user is online on the hotspot/network.
Or if they are coerced to go to a spoof site with a certificate made with your private key. Are you guarding your private key with the same measure of caution and diligence as, say, http://www.nordea.com/ or a CA like Symantec???
Bad all the way around. Your actions actually make it easier for your users to be scammed / infected.
-
Derelict:
I understand your concern with leaking private keys.But, first, the attacker must gain the private key.
Second, the attacker needs to find a victim that has my root cert installed.
Then the attacker needs to coerce that user into going into a spoof site.Thats NOT a easy thing to do.
And actually, Let's encrypt, have made SSL even worse now. Now ANYONE, including www.n0rdea.com (note the zero) can get a free SSL certificate to their site, so the attackers don't even need to hunt after my CA private key. They just go to let's encrypt, and they could even manually create the certificate as the 3 month expiry would be enough to carry out a successful phishing/scam attack.
That, on top of the problems that SSL creates with encrypted malware, problems that a proxy cannot see the GET URL, which means phishing sites hosted at free webhosting is harder to block (without causing colleteral damage and blocking every website at that webhost), and much more. And not enough with that, now google uses SSL as a ranking indicator, which means sites that really don't need SSL, gets SSL to get a better score in google's algoritm, combined with vulnerable upload scripts, so people could upload malware to for example simple photo hosting sites and such.
Do you remember that time when SSL was created? The netscape times, with the good ol' 33k modems?
Then SSL was something that only banks could get due to strong encryption laws in USA. Driveby downloads was a very rare thing, malware mostly spread by diskettes.That was the GOOD times. Then all could know that if they was on a site with the yellow little padlock in the bottom corner, then they was on a safe, vetted and good site. And antivirus proxies didn't need to scan these sites because they were known good sites, so antivirus proxies only needed to pass SSL unchanged, there was no risk in that.
After that, they loosened on the laws and allow 56bit encryption to be used by non-banks, why this thing with SGC (Server Gated Crypto) certificates was created, so banks could still use 128 bit encryption, but other sites needed 56bit. That was somewhat worser, but still, a certificate could only be issued to a organization that had a valid track record and vas trusted, so there was still a big roadblock for bad people to create SSL sites, so still, there was no need for SSL antivirus.
And then it went amok. Yes, really amok.
It started with free SSL CA's. So malicious people could go and get SSL certificates. But the good thing with these, was that these was valid for 1 year, and you couldn't get a new while you already had one issued, so if your phishing/malware/spam/hack domain got blocked, then no new certificate for you, you had to wait until that expired.And today, it has gone totally out of control. Let's encrypt are causing almost 100% SSL deployment.
How should you be able to find viruses in traffic?Someone needs to put some brakes on that SSL wheel that are spinning wayy to fast now!
Theres a reason most antivirus and threat companyes apply SSL filtering nowadays:
https://blog.avast.com/2015/05/25/explaining-avasts-https-scanning-feature/
https://www.bluecoat.com/security/security-archive/2012-06-18/growing-need-ssl-inspection
https://support.kaspersky.com/6851
http://nod32.helpmax.net/en/antivirus-protection/protocol-filtering/encrypted-ssl-communication/I think you should reconsider whats really happened with SSL, and why SSL, in some cases can be bad, and why it can become neccessary for a network administrator, to uncover and scan SSL traffic.
Of course, such scanning should not be used for malicious purposes, and as for example with lock picks, that can be used for good purposes (for example if your key become broken), but also for malicious purposes (breaking and entering), its the same thing with SSL proxies.When I set up network security, I prefer to put everything that is about security, in a central place. Eg, let pfSense be a thick, hard shell around the network, and almost no security inside.
And to accomplish that, you need to use features like SSL scanning, blocklists over malware and phishing and such things, and very tight firewall rules, so nothing slip through unscanned.So I wonder, why are you getting so upset about scanning SSL-traffic? Its kinda like SSL was some holy grail that nobody should touch.
-
It's not the scanning HTTPS traffic that's the issue. It's that you're having users install something on their machine that fetches a HTTP URL and installs any CA certificate that's returned as a trusted root certificate. So anyone that can intercept traffic from their system can install a trusted root cert and completely compromise everything on their machine that uses PKI. HTTPS, certain VPN types, and more. It's a massive security hole.
If this was a corporate network and you owned all the machines, then installing your own root CA is acceptable if management deems it appropriate. You own the machines. You'd still be insane to install trusted CAs fetched via HTTP, but it's within your right to do whatever you want to machines you own. Doing it to someone else's machine is completely unacceptable even without the automatic fetch and install "feature".
What AV vendors do there isn't comparable to what you're doing. But pointing to them as a reference isn't an indication that it's a good idea, as many of them have made major screw ups in those implementations that leaves systems vulnerable. This is more comparable to how Dell massively screwed up.
I guarantee you aren't controlling your private key adequately to be considered a root CA. What happens when your private key is compromised? Can't revoke it without manually removing that cert from every system you've infected.
How are you supposed to find viruses in HTTPS traffic on a public network? You don't! You're effectively an ISP, your responsibility is to pass packets. Certain security mechanisms to protect systems are appropriate, like client isolation on your APs. But you should never, under any circumstances, change anything on a client system you don't own.
-
But why did you then remove the cpauth.php and cpauth2.php from the first post then?
Those 2 files had nothing with automatic installation to do. The cpauth.php and cpauth2.php was made for manual certificate installation, eg where the user manually downloads the .cer/.pem file and install.You say its unacceptable to fetch and install certificates over HTTP, even if done manually.
but, cpauth.php and cpauth2.php was, as I described in the first post, designed to be loaded over HTTPS. (else they won't function at all since HSTS is required for the whole function)And as I wrote in the post, if the user is unconfortable with manually installing a certificate on their system, they can simply refuse to use the network. Nobody forces them to use that particular network.
And then its not I that change something on systems that I don't own, then its the user itself that does it.And also as I described, this was not only for hotspot, but more commonly, BYOD, where a corporation provides a closed network to its employee's, where employee's can itself connect their own devices, and thus compliance can be required, and here it could be good with having the user install a cert to make it possible to scan incoming traffic for threats, but also scan outgoing traffic for Data Loss Prevention.
-
~~To me, SSL connections between two parties I do not know are sacred. Nor do I have any desire to have a trusted certificate for which I hold the private key installed in random users' systems.
I also think developments like Let's Encrypt are a good thing, not a bad thing.
If I control one endpoint, like a private network used by my employees, then I have the authority to deploy an enterprise root certificate for use by my SSL proxy.
In my personal opinion, you should take a long look at whether you want to be providing Internet access to the general public based on what the Internet is today, crypto and all.~~
That's been sitting unsent in a compose window. Seems it has already been said. :) -
@cmb:
It's not the scanning HTTPS traffic that's the issue. It's that you're having users install something on their machine that fetches a HTTP URL and installs any CA certificate that's returned as a trusted root certificate. So anyone that can intercept traffic from their system can install a trusted root cert and completely compromise everything on their machine that uses PKI. HTTPS, certain VPN types, and more. It's a massive security hole.
If this was a corporate network and you owned all the machines, then installing your own root CA is acceptable if management deems it appropriate. You own the machines. You'd still be insane to install trusted CAs fetched via HTTP, but it's within your right to do whatever you want to machines you own. Doing it to someone else's machine is completely unacceptable even without the automatic fetch and install "feature".
What AV vendors do there isn't comparable to what you're doing. But pointing to them as a reference isn't an indication that it's a good idea, as many of them have made major screw ups in those implementations that leaves systems vulnerable. This is more comparable to how Dell massively screwed up.
I guarantee you aren't controlling your private key adequately to be considered a root CA. What happens when your private key is compromised? Can't revoke it without manually removing that cert from every system you've infected.
How are you supposed to find viruses in HTTPS traffic on a public network? You don't! You're effectively an ISP, your responsibility is to pass packets. Certain security mechanisms to protect systems are appropriate, like client isolation on your APs. But you should never, under any circumstances, change anything on a client system you don't own.
Well if you have a better way to scan HTTPS traffic for malicious packets cmb then we are waiting to hear it. The fact that encrypted malware traffic can travel through networks to endpoints, and completely escape inspection, is also a massive security hole. It is not for you to make decision for other administrators about what is the greater threat, and you don't know the level of control they maintain over client systems.
In addition, he, nor any network administrator is "doing something to someone else's machine". Users cannot be forced to install trusted CAs; the users are doing the installing in this case if they want to access the corporate network etc.
Again, this method has many more protective uses than trying to find viruses on public networks or acting as an unauthorized snooping tool. And again, the clients are actively changing something on their system as a condition of gaining access to network resources.
You made a lot of good points about security flaws of https inspection in general, but there are going to be flaws, and trade-offs to any method. You may think you know better about a certain admin's network, but you don't, because you don't have access to the infrastructure design or the individual security concerns. Each network has its own caveats and use cases.
Thanks for posting this useful guide sebastiannielsen.
-
So you want the postal service to open each letter and each parcel, in some might be bombs. Or drugs. Or or or… I which kind of weird world do you life that you think you have to "protect" adult people from "malicious packages"?
Do you want to buy a beer even after you already had two or three and the barkeeper won't sell it to you? As an adult, what would you think?
Users are adults, they can take responsibility for what we do and NOBODY has to tell them what site to visit and which content to look at (as long as it's not illegal, but that's not YOUR piece of cake, but the police has to take care).
What is so hard to understand about that? Keep your fingers away from the data of your users. End of story. Otherwise move to China, North Korea or Iran and get a nice federal admin job with your kind of attitude. In Western, democratic countries your attitude is only acceptable for NSA, GCHQ and other thought crime organizations.
-
Really… with the straw man arguments?
The postal service already has ways of inspecting parcels for the things you mentioned, which don't include opening each and every letter and parcel, so my opinions on that matter are irrelevant, it's already taking place. That's totally off-topic as well.
Admins have to protect adult people from malicious packages all the time in enterprise environments where millions of dollars of equipment and intellectual property are at stake, and this guide helps lighten the load on administrators.
Do you not understand application layer packet inspection or what? Were you okay with it before the rise of https? Or have you always been against high-layer packet inspection? If that's the case, you haven't had any experience with high-security environments.
This isn't the electronic frontier foundation forum man, the OP provided a useful guide on how to configure pfsense for a special-use case.
-
Yeah, in "enterprise" environment you can life your paternalistic wet dreams.
I know some decent countries you go to jail for something like this MITM plot. And I'm proud of the respective legislation there.
Because I know that nerds like you are managing open WLAN I removed all wireless stuff completely from my computers. I don't want to get infected with this kind of malware just by the whims of some misanthrope "admins".
Hope you stay in your China-North Korea corner of the world and get happy there!
It's a shame to have such a thread in a security forum of an opensource firewall AT ALL.
-
Well if you have a better way to scan HTTPS traffic for malicious packets cmb then we are waiting to hear it. The fact that encrypted malware traffic can travel through networks to endpoints, and completely escape inspection, is also a massive security hole. It is not for you to make decision for other administrators about what is the greater threat, and you don't know the level of control they maintain over client systems.
You're talking about a scenario where you own the endpoints. If you own the systems and decide that's what you want to do, fine, as I already said.
OP's talking about a public access network, forcing people to create a serious security hole on their computers to use a public wifi network. That's unacceptable. There's a reason no one (else) does this.
-
Also about the "Dell root certificate" issue, I don't think that was a bad thing really.
However, the "Superfish root certificate" was a very bad thing to do.The major difference between these 2, is intent.
The dell root certificate was done for the users own good, to make updating the computer through a automated scheduled-updates tool, more easier, by having the software package drivers and updates client-side, and then "self-sign" them, so the system would not reject to install the drivers. Yes, there was a big flaw that compromised eavesdropping security on those computers, but still, it was not done for bad purposes, it was rather done to improve the security by making sure the computer always had the latest updates. It was just that the implementation was bad by having one certificate for all computers, instead of generating a unique certificate for each computer.
The Superfish certificate however, was a very bad thing. Extremely bad. The reason that was bad, is that the Superfish certificate was only made for one single purpose: To shove money into the wrong people's pockets, by showing third-party ads on websites. (Adware). That certificate would be bad even if they generated a unique one per computer.
Think like TSA locks. They compromise the security of people's bags because they are extremely easy to pick and the keys are leaked (link to news site) for a long time ago. And in the same way, regular locks are compromised too by using bolt cutters, so when the bag arrive at baggage, anyone can go through them and steal content or place contraband. But they do improve airport security because TSA officials can go through the bags for bombs. And I bet that if you would try to check in a safe, the TSA officials would demand you to give the code to the safe to check it. (and no, they won't allow you to open it in-person due to the classified areas that the inspection is made on, either you give the code or the safe, and you, is not getting aboard)
And if they don't want their content gone through by TSA officials, they don't need to use a Airport.
And in the same way:
If they don't want to install the certificate, they don't need to use my network. The certificate install isn't fully automatic, the user still needs to click on a link and then confirm a security warning, to install.Personally, I think eavesdropping (by untrusted parties, like hackers and such) are so uncommon, that eavesdropping security (encryption) can be safely traded for malware security (virus scanning), even if that makes eavesdropping by anyone possible.
When was the last time you heard somebody eavesdropping on a connection such as sensitive details could be stolen? Today, sensitive details are usually stolen via Phishing, and with the new Let's Encrypt, that is even made worser because now many phishing sites have that "Trusted lock" icon too, while it evade any Phishing filters (that do GET URL scanning).
When was the last time you heard someone was infected by a driveby download? I hear about it almost everyday.
Last time I got infected by a driveby was just about a month or two before I installed my 2.3 pfSense firewall (I even have the date in my event logs: 2016-03-10). It was a ad-supported forum, that opened a popup ad. A few seconds later, there was a lot of shortcuts on my desktop that Microsoft Edge had created, and then something started up that always showed a casino ad each time my computer started up, and also casino ads on every page (even this page).
Had to uninstall a lot of crap (lots of EXE's like uac_skip.exe and such in my Temp & system32 folder) and run antispyware, antivirus, and such. And as the "thing" modified browser components, it could display its ads even on SSL protected pages. I think the modification in my browser components are still there, but they are inactive now as the software that interfaces these modified browser components are gone.And no, I didnt' need to click on anything, everything just did itself fully automatic. And no, MSE didn't catch it either.
And THAT was a much more major compromise than even installing the eDellRoot certificate would be. Because that Adware could have keylogged my computer regardless of if it were, and sent all my details to completely untrusted indivuals, that would misuse the details to steal money.Now, with pfSense and good AV signatures, the same popup window on the same site is blocked by squidClamav. (some JS exploit it reports)
cmb: What would you choose?
That casino auto-download and no root certificate install.
Or, install my rootcertificate, and not get that casino auto-download.Personally, I would choose the second, even if that meant that my ISP or the hotspot im currently on, could read all my banking traffic. Because if I select a particular ISP, or a particular hotspot, I do it because I trust that ISP or hotspot. I would never sign up for a ISP or use a hotspot I didn't trust.
And I think same should apply for everyone. Don't use a ISP or hotspot if you don't fully trust the owners of that (in such a way that you would even trust them with your banking credentials).I Trust my ISP, and that why I choose them. I even sent my banking credentials to them when they couldn't find the payment for a bill, and allowed them to logon to my bank account. They finally found the payment when it turned out to be a misspelled reference ID.
I think people need to trust other people more, and not just blindly encrypt everything? Or what do you think?
-
I think you're insane. I don't trust anything outside my WAN interface. I don't trust much on the inside either. Lots of crypto there too.
I would disconnect the internet before I would install a trusted root cert from my ISP. I would NEVER EVER EVER trust a root cert from some wifi hotspot.
Wifi hotspots are some of the most notoriously insecure networks on the planet, but you say you trust them. Or at least you trust the ones you choose to use.
That casino auto-download and no root certificate install.
Or, install my rootcertificate, and not get that casino auto-download.Auto-download every single time. I'd rather get crypto locker than install your root cert. I don't need you to protect me, thank you very much.
-
Then we are quite different. Maybe its because my AS?
Why would you not trust your ISP? Why not change to a ISP you can trust?
I can understand however that you don't trust anything outside the WAN, as it are many hackers outside there that are constantly scanning for IPs and trying to get their things into everyone's computer.About hotspots, its exactly that. I select hotspots carefully. I don't blindly connect to "R4nd0mH0tsp0t" in a untrusted suburban area, but rather, I select good hotspots I know they are run by good indivuals, and have adequate security like fake hotspot detection and ARP spoofing prevention, which both McD, Espressohouse, my network (builtin my DAP-2695), and Telia hotspots in my local area do have. And also when im home at other people, I would only connect to their wifi if Im currently visiting someone I trust.
-
This here makes my worst dreams come true about the thinking/behavior of admins. Please tell me all this here is comedy. PLEAAAASE!
I'm not really sure, but even in Sweden (the land of Censilia Malmstöm https://en.wikipedia.org/wiki/Cecilia_Malmström) this should be illegal, after all….
-
cmb: What would you choose?
That casino auto-download and no root certificate install.
Or, install my rootcertificate, and not get that casino auto-download.Poll added. See top of thread.
-
Sebastian, after our PM exchange, I have to confess: I can't take this here serious any more. Sorry. Bye.
-
The NSA has a certificate they would like you to install…
