On 21/07/2019 03:21, My1 wrote:
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.
I believe this is either done, or easy to add.
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.
Hence my breakdown and suggestions below, which seem to agree with yours
in most cases.
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.
As for on-machine antivirus, hence my suggestion to locally (on
machine) use a protocol already implemented for corporate users by the
larger antivirus companies (ICAP).
There are legitimate security programs that remove certain received
data, such as removing embedded loads of government pushed tracking
beacons.
Similar, many higher end personal security packages have features
to prevent the less experienced family members from revealing their
home address or other such details to physically dangerous people,
the appropriateness of such features should be a family decision,
not a browser decision.
However there should be browser settings to choose the level of
scanning entrusted to each local scanner (scan post yes/no,
scan file upload yes/no, modify post/upload data yes/no,
scan URLs yes/no, modify server replies yes/no).
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.
DANE has some unfortunately implementation difficulties, mostly
inherited from DNSSEC. It would be unfortunate to limit home or
company internal systems to mechanisms essentially different
from how the same job is done elsewhere, especially for testing
stuff.
Ways to recognize type 5 scenarios could include (with combinations
occurring in any one situation) could be:
- DNS names in the guaranteed non-public TLDs: .local, .lan, .example,
.invalid etc.
- DNS names outside all TLDs listed in the public suffix list included
with the browsers. (for example .somefamilynickname).
- DNS names at least 2 levels below public suffixes and not existing
on DNS in the public Internet. Need someone highly trusted to check
this without revealing the probed DNS names widely. (For example
internal.example.com with .com being the public suffix and the
example.com DNS servers controlled by the home/company).
- IPv4 addresses from the RFC1918 and 127.x.x.x ranges of LAN IPs (in IP
subject-alt-names).
- IPv6 addresses from the ranges similarly reserved for non-public use.
- CAA record somehow matching the private CA and not any of the browser-
bundled CAs.
- e-mail certificates will be harder to separate as public e-mail certs
are kind of unpopular except government citizen CA schemes.
the only problem with your idea of categorizing these issues is how to
differentiate 3 and 4 from 2.
Indeed, hence the need for heuristics and countermeasures.
#3 would probably become a #2 warning in all but the most strictly
identifiable cases.
#4 could be transitioned to a cross-vendor AV API, such as ICAP to
localhost or a plugin API much simpler than NPAPI.
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.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
