TLS, TLS MITM, and TLS MITM detection are tools; that's all they are. They have their advantages and disadvantages, and can be used for good or for evil, depending on the intentions and/or the competence of the parties involved.
Frankly, I see a case for the use of both. Let us take the example of a bank. For accessing your accounts on the bank's website, it would be a very good thing if they could detect that that even though you landed on their login page via TLS, something has intercepted the connection and downgraded you from TLS 1.2 using ChaCha20-Poly1305 to TLS1 using 3DES- MD5 and throw up a warning that your encrypted connection may have been intercepted and your password and accounts might be at risk if you continue to sign in. It doesn't matter whether that TLS intercept is happening on a coffee shop wifi that's been popped by the kid in the apartment across the street with a cantenna, or the SuperSecure(TM) feature of Grandma's new Comcast cable modem. I sure as hell would want to know that someone has been monkeying maliciously or incompetently with my encryption before signing into a page from which my life savings and investments can be controlled.
But on the other hand, let us take the case of individual workstations within that bank's internal network. A call center operator is going to be signing into various accounts and have at least some degree of access to sensitive data, like account numbers, balances, PII, etc. All the data breeches in the news point out how important it is to keep this data from leaking, and it is absolutely in that bank's security department to be able to monitor and control what data is entering and leaving those workstations, including on encrypted channels. Again, it doesn't matter whether that's blocking inbound malvertisements from lunchtime Facebook browsing, or a clever outbound data exfiltration channel.
On the gripping hand, I recall one of the security folks at Google commenting on their bugtracker that local anti-virus' TLS intercept was one of their biggest impediments to securing the browser. And the bank's internal TLS intercept in the above scenario does make for a high-priority target for an attacker, and is potentially a Game-Over-class single point of failure were it popped.
I'm personally of the opinion that TLS interception is a bad idea in most cases, and making it less common is a net win for overall privacy and security for all involved. But, it is a tool, and can have valid uses.
Frankly, I see a case for the use of both. Let us take the example of a bank. For accessing your accounts on the bank's website, it would be a very good thing if they could detect that that even though you landed on their login page via TLS, something has intercepted the connection and downgraded you from TLS 1.2 using ChaCha20-Poly1305 to TLS1 using 3DES- MD5 and throw up a warning that your encrypted connection may have been intercepted and your password and accounts might be at risk if you continue to sign in. It doesn't matter whether that TLS intercept is happening on a coffee shop wifi that's been popped by the kid in the apartment across the street with a cantenna, or the SuperSecure(TM) feature of Grandma's new Comcast cable modem. I sure as hell would want to know that someone has been monkeying maliciously or incompetently with my encryption before signing into a page from which my life savings and investments can be controlled.
But on the other hand, let us take the case of individual workstations within that bank's internal network. A call center operator is going to be signing into various accounts and have at least some degree of access to sensitive data, like account numbers, balances, PII, etc. All the data breeches in the news point out how important it is to keep this data from leaking, and it is absolutely in that bank's security department to be able to monitor and control what data is entering and leaving those workstations, including on encrypted channels. Again, it doesn't matter whether that's blocking inbound malvertisements from lunchtime Facebook browsing, or a clever outbound data exfiltration channel.
On the gripping hand, I recall one of the security folks at Google commenting on their bugtracker that local anti-virus' TLS intercept was one of their biggest impediments to securing the browser. And the bank's internal TLS intercept in the above scenario does make for a high-priority target for an attacker, and is potentially a Game-Over-class single point of failure were it popped.
I'm personally of the opinion that TLS interception is a bad idea in most cases, and making it less common is a net win for overall privacy and security for all involved. But, it is a tool, and can have valid uses.