Home Network Design
-
The AC-LR I have is pretty clearly labelled 24V and it's a few years old now. I doubt you have that.
-
@jt40 said in Home Network Design:
@bpsdtzpw Serial number: 4200000210619acc88
This cert does not exist on https://crt.sh . The only hit that Google returns is this conversation. I suspect you're running Kaspersky and it's MITMing your https connections, thus giving this alternate certificate chain. What happens if you use the same browser to navigate to https://www.amazon.com , and look at the cert chain? It should be www.amazon.com -> DigiCert Global CA G2 -> DigiCert Global Root G2 . If there's Kaspersky in there, it's MITMing your connection.
-
@bpsdtzpw Yes, it's doing deep scanning of every connection, also HTTPS, but I didn't know that it behaves in this way for the certs...
I also have the Windows Certificate store in use from KS, it's weird that it performs such task.
On top of that, I don't know where I can disable such thing, it must be a built-in function between the HTTPS scanning or other network scanning options. -
@jt40 said in Home Network Design:
@bpsdtzpw Yes, it's doing deep scanning of every connection, also HTTPS, but I didn't know that it behaves in this way for the certs...
I also have the Windows Certificate store in use from KS, it's weird that it performs such task.Yeah, that's how HTTPS scanning typically works, since the encryption is assumed to be (should be) unbreakable. So the scanner acts as a proxy between your browser (system, if the scanner installer put its root cert in your system root store -- shiver!) and the website. That is, your browser forms an HTTPS connection to the scanner, which allows the scanner to decrypt the traffic and scan it, then the scanner forms an HTTPS connection to the website.
The browser-to-scanner connection is thus encrypted with the key from a cert with a wildcard DNS name that matches every possible website. This leaf cert is then signed by a root cert for the scanner "CA". The scanner's installer installs that root cert in your browser's root store so that the browser recognizes the leaf cert as valid.
All this rigamarole means that you can no longer use the browser to determine what cert chain the website actually uses. You need |dig| or some other such tool for that.
On top of that, I don't know where I can disable such thing, it must be a built-in function between the HTTPS scanning or other network scanning options.
Your scanner should provide some UI to disable HTTPS scanning.
-
@bpsdtzpw said in Home Network Design:
Your scanner should provide some UI to disable HTTPS scanning.
This! There is no possible way the benefit of whatever that software is doing that would be worth giving them access to all the encrypted stuff you might be doing - login to your bank accounts for starters..
-
@johnpoz Ya. FWIW, Kaspersky is based in Russia, and is currently banned on U.S. government systems and those of U.S. government contractors and subcontractors. https://www.wsj.com/articles/u-s-government-formalizes-kaspersky-ban-11568194206 ; https://www.securityweek.com/kasperskys-us-government-ban-upheld-appeals-court . But any scanner (ha! any program!) with network access creates potential risks. There is no free lunch in this area.
-
@johnpoz said in Home Network Design:
@bpsdtzpw said in Home Network Design:
Your scanner should provide some UI to disable HTTPS scanning.
This! There is no possible way the benefit of whatever that software is doing that would be worth giving them access to all the encrypted stuff you might be doing - login to your bank accounts for starters..
@bpsdtzpw said in Home Network Design:
@jt40 said in Home Network Design:
@bpsdtzpw Yes, it's doing deep scanning of every connection, also HTTPS, but I didn't know that it behaves in this way for the certs...
I also have the Windows Certificate store in use from KS, it's weird that it performs such task.Yeah, that's how HTTPS scanning typically works, since the encryption is assumed to be (should be) unbreakable. So the scanner acts as a proxy between your browser (system, if the scanner installer put its root cert in your system root store -- shiver!) and the website. That is, your browser forms an HTTPS connection to the scanner, which allows the scanner to decrypt the traffic and scan it, then the scanner forms an HTTPS connection to the website.
The browser-to-scanner connection is thus encrypted with the key from a cert with a wildcard DNS name that matches every possible website. This leaf cert is then signed by a root cert for the scanner "CA". The scanner's installer installs that root cert in your browser's root store so that the browser recognizes the leaf cert as valid.
All this rigamarole means that you can no longer use the browser to determine what cert chain the website actually uses. You need |dig| or some other such tool for that.
On top of that, I don't know where I can disable such thing, it must be a built-in function between the HTTPS scanning or other network scanning options.
Your scanner should provide some UI to disable HTTPS scanning.
I don't think that it works in that way, the proxy acts as an third party entity that makes the request.
The scanning of encrypted communications doesn't work on the whole communication, it works on the header mainly, or only the header.
The content (body) of the communication it's encrypted end to end, there is no way a proxy or scanner can decrypt such data, it's alwasy the browser (endpoint) to manage the communication with the keys, the keys are not managed in anyhow from the AV, it would be a great zero day for a browser.This is what I know about it, but I could investigate more with Wireshark...
@bpsdtzpw said in Home Network Design:
@johnpoz Ya. FWIW, Kaspersky is based in Russia, and is currently banned on U.S. government systems and those of U.S. government contractors and subcontractors. https://www.wsj.com/articles/u-s-government-formalizes-kaspersky-ban-11568194206 ; https://www.securityweek.com/kasperskys-us-government-ban-upheld-appeals-court . But any scanner (ha! any program!) with network access creates potential risks. There is no free lunch in this area.
The story in US is like the one with Huawei, shall I comment? :D
The problem with KS is that it was in use by sensitive government institutions, so there was an obvious fear which lead to the ban, aside that, it's only cosmetics I guess.Last thing, no banking with Windows, are you joking guys? :D
-
@jt40 said in Home Network Design:
The scanning of encrypted communications doesn't work on the whole communication, it works on the header mainly, or only the header.
The content (body) of the communication it's encrypted end to end, there is no way a proxy or scanner can decrypt such data, it's alwasy the browser (endpoint) to manage the communication with the keys, the keys are not managed in anyhow from the AV, it would be a great zero day for a browser.That's exactly what it does. It breaks the end to end encryption. It can see everything in the connection. If it couldn't it wouldn't be able to scan anything.
Steve
-
@jt40 said in Home Network Design:
no banking with Windows
I don't think anyone said that - what I said is I wouldn't run some software that does MITM on my https connections..
I bank on my windows machine and even my phone all the time - but what I don't run is some so called "security" software that breaks my end to end encryption to "protect me" ;)
-
@jt40 said in Home Network Design:
I don't think that it works in that way, the proxy acts as an third party entity that makes the request.
The scanning of encrypted communications doesn't work on the whole communication, it works on the header mainly, or only the header.
The content (body) of the communication it's encrypted end to end, there is no way a proxy or scanner can decrypt such data, it's alwasy the browser (endpoint) to manage the communication with the keys, the keys are not managed in anyhow from the AV, it would be a great zero day for a browser.That is how deep inspection works. See, e.g., https://www.fortinetguru.com/2019/11/ssl-inspection-certificate-inspection-deep-inspection/ .
When you use deep inspection, the FortiGate impersonates the recipient of the originating SSL session, then decrypts and inspects the content to find threats and block them. It then re-encrypts the content and sends it to the real recipient.It's possible to inspect only the (unencrypted) SSL handshake without MITMing the connection with a pseudo-CA cert, but the fact that your config returns a Kaspersky "CA" cert in the chain to the target website indicates that you're using deep inspection. My non-MITM config returns the chain dlinkmea.com -> cPanel, Inc. Certification Authority -> COMODO RSA Certification Authority , which is exactly the chain indicated by https://crt.sh/?id=5515086855 .
This is what I know about it, but I could investigate more with Wireshark...
Yep.
You can also ask your browser to display the cert chain to dlinkmea.com . I think what you'll see is SAN (subject alt name) *.* -> Kaspersky intermediate CA -> Kaspersky root CA.
-
Thank you all, that has been an interesting conversation.
When I made the setup, I was probably not aware of it, or I wasn't concerned about it, as long as KS doesn't send these data somewhere, which I doubt, I'll still run an investigation though.
For the moment, what I know is that the traffic is not enough to dump something on their servers, as well as the addresses that it reaches, they are meant for specific purposes and I guess that security measures are in constant review.
On top of that, something like that would crack down the company forever, as a security company I'm pretty sure that no one is pushing thecode skipping the audit process in the build... -
@jt40 I don't care who the maker of the software was - I would not be keen to anything doing mitm on my ssl conversations..
Its not good idea from security/privacy point of view. And the benefits even if all on the up and up are going to be minimal at best for such a breach in your end to end encryption.
Now I can see where it might want to be done from a company point of view - most likely more concerned with DLP.. But it is a whole can of worms that even companies are wary of opening.
-
@johnpoz Companies do it, also with other tools, like dedicated proxies etc...
They go against the law in almost every country, the excuse of "the laptop is company asset and we monitor what we want" it's actually wrong, they could monitor only the communications of their business, but nothing private.
Unfortunately, they monitor all in the same way, too much manual work to monitor only company resources, at least at that level.
Otherwise, DNS/IP blocks etc are much easier.DLP is an interesting point, I think you mean from a network point of view considering the previous messages.
Fact is, there is always the way to sneak out and no one is constantly monitoring you...
It's much easier to protect the project at higher level, rather than looking each network packet, plus there is a tiny line between legal and illegal.
What I noticed is that in the recent years, almost in every enterprise nothing is restricted in terms of online resources, you can access everywhere, no one cares of what you do, but I've seen these proxies...
Obviously, they are scared about file system DLP :D , as soon as you plug in an USB device all the security department will know it :D , plus it won't allow you. -
@jt40 I have ran content filtering and security for multiple companies over the years - I know exactly what they do an don't do ;) And how they do it and what they can do..
And MITM is a can of worms that many will not open - that you take it upon yourself to do it - with a company that has had questions, and is banned in some countries on gov type computers..
Filtering where a user can go is simple enough to do with explicit proxies having to be set without having to break the end to end encryption of the ssl connection. I don't have to peek inside your ssl connection to block you from going to xyz.com or allowing you to go to abc.com via https.
Well you do you..
