Hello everyone, I am new here but also want to share my opinion about some posts here, I know it's a lot of text but I hope it's not too bad.
Am Freitag, 19. Juli 2019 23:42:47 UTC+2 schrieb dav...@gmail.com: > Wouldn't it be easier to just decree that HTTPS is illegal and block all > outbound 443 (only plain-text readable comms are allowed)? Then you would > not have the decrypt-encrypt/decrypt-encrypt slowdown from the MITM. if you want to block like half the internet or more which is on the way of HTTPS-only, go ahead. > If you don't want to make everyone install a certificate: > Issue a double-wildcard certificate (*.*) that can impersonate any site, load > it on a BlueCoat system, and sell it to a repressive regime: > https://www.dailydot.com/news/blue-coat-syria-iran-spying-software/ > > Both scenarios end up in the same place: Nobody trusts encryption/SSL or CAs > anymore. As far as I remember, certs only allow one wildcard and that only on the very left so they would need at least *.tld and *.common-sub.tld for all eTLDs (*.jp doesnt cover *.co.jp). Also, you say that this is for not wanting everyone to install a certificate. which Trusted CA in their right mind would actually do this? CT is becoming FAR bigger as time goes on and if any CA is catched going and issuing wildcards for public suffixes, that CA would be dead instantly. Also browsers could just drop certificates with *.(public-suffix) entirely and not trust them, no matter the source. > On Friday, July 19, 2019 at 1:27:17 PM UTC-7, Jakob Bohm wrote: > > On 19/07/2019 21:13, andrey...@gmail.com wrote: > > > I am confused. Since when Mozilla is under obligation to provide > > > customized solutions for corporate MITM? IMHO, corporations, if needed, > > > can hire someone else to develop their own forks of Chrome/Firefox to do > > > snooping on HTTPS connections. > > > > > > In regular browsers, developed by community effort and with public funds, > > > ALL MiTM certificates should be just permanently banned, no? > > > > > > > As others (and I) have mentioned, MitM is also how many ordinary > > antivirus programs protect users from attacks. The hard part is > > how to distinguish between malicious and user-helping systems. I fully agree that this is hard but one also needs to be aware that antiviruses while not unhelpful also provide risks by being VERY deep in the system. an unmonitored MITM action by that could end in disastrous results, in the worst case bank phishing could occur since the user cannot verify the certificate via the browser. one suggestion I think might be helpful is to have the entire data available, while keeping the HTTPS signature, and there could be a machanism that allows anti-virus software to check content before it is executed/loaded and if needed, put a big "do not execute" flag for certain things like script blocks that are clearly malicious or whatever, and the browser can check the signature that no content has been actually changed, but remove that flagged content, while displaying a notification that content has been blocked. that way anti-viruses could only remove elements but not actually change anything. Am Freitag, 19. Juli 2019 22:23:00 UTC+2 schrieb Jakob Bohm: > As someone actually running a corporate network, I would like to > emphasize that it is essential that such mechanisms try to clearly > distinguish the 5 common cases (listed by decreasing harmfulness). > > 1. A known malicious actor is intercepting communication (such as the > nation state here discussed). > > 2. An unknown actor is intercepting communication (hard to identify > safely, but there are meaningful heuristic tests). > > 3. A local/site/company network firewall is intercepting communications > for well-defined purposes known to the user, such as blocking virus > downloads, blocking surreptitious access to malicious sites or > scanning all outgoing data for known parts of site secrets (for > example the Coca-Cola company could block all HTTPS posts containing > their famous recipe, or a hospital could block posts of patient > records to unauthorized parties). This case justifies a non-blocking > notification such as a different-color HTTPS icon. > > 4. An on-device security program, such as a local antivirus, does MitM > for local scanning between the browser and the network. Mozilla could > work with the AV community to have a way to explicitly recognize the > per machine MitM certs of reputable AV vendors (regardless of > political sanctions against some such companies). For example, > browsers could provide a common cross-browser cross-platform API for > passing the decoded traffic to local antivirus products, without each > AV-vendor writing (sometimes unreliable) plugins for each browser > brand and version, while also not requiring browser vendors to write > specific code for each AV product. Maybe the ICAP protocol used for > virus scanning in firewalls, but run against 127.0.0.1 / ::1 (RFC3507 > only discusses its use for HTTP filtering, but it was widely used for > scanning content from mail protocols etc. and a lot less for > insertion of advertising which is in the RFC). > > 5. A site, organization or other non-member CA that issues only non-MitM > certificates according to a user-accepted policy. Those would > typically only issue for domains that request this or are otherwise > closely aligned with the user organization. Such a CA would > (obviously) not be bound by Mozilla or CAB/F policies, but may need to > do some specific token gestures to programmatically clarify their > harmlessness, such as not issuing certs for browser pinned domains, > only issue for domains listing them in CAA records or outside public > DNS or similar. > > I am aware of at least one system being overly alarmist about our > internal type 5 situation, making it impossible to distinguish from a > type 1 or 2 attack situation. let me go over each of your situations and what I think of those: 1) obviously needs a VERY clear warning including the specific information about the actor like who is the interceptor 2) similar to 1 but obviously it cannot have the specific information that is known about a, well, known actor. 3 and 4 are similar but there should be a "lesser" click-through warning that just informs the user for example once per session that he is on watch (because while these things can filter bad stuff, they can also read sensitive inputs like passwords), while the cert if it can be retrieved from a "trusted" source, for example the active directory, while 4 shouldnt be using classic MITM scenarios at all, see my idea above. I don't know how or even whether or not it is possible to have one client prove to another that site X actually came in via HTTPS and was signed using X, because of all the ephemeral keys and everything, but that way a proxy could be made that securely transmits data from websites to the client, while also flagging content that should not be touched. obviously with a notification if any of these flags occur. 5) is a fairly valid case and in my opinion DANE is a decent way to deal with that, only the browsers need to play along. the only problem with your idea of categorizing these issues is how to differentiate 3 and 4 from 2. in the classic MITM style scenario anything could have installed the MITM CA and in case of 4 the private key is even on that computer. a field day for malware. there would need to be a verifiable source for the MITM CA, to not be seen as 2. for case 4 at least one could make it much less ugly by only transmitting recieved data to the software while inputs stay secret, but in case 3 where we want to scan and filter inputs, this is obviously not possible. Regards, My1 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
