From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-user+bounces-196138-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 956E71382C5 for <garchives@archives.gentoo.org>; Wed, 2 Jun 2021 01:13:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BF716E0843; Wed, 2 Jun 2021 01:13:49 +0000 (UTC) Received: from icp-osb-irony-out2.external.iinet.net.au (icp-osb-irony-out2.external.iinet.net.au [203.59.1.155]) by pigeon.gentoo.org (Postfix) with ESMTP id D7B44E0839 for <gentoo-user@lists.gentoo.org>; Wed, 2 Jun 2021 01:13:47 +0000 (UTC) X-SMTP-MATCH: 0 IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ABX1YeqOK7/84fMBcTj+jsMiBIKoaSvp037?= =?us-ascii?q?BN7TEVdfU1SL37qynKpp8mPHDP5Qr5J0tQ/exoVJPtfZvznaQFkLX5F43SOj?= =?us-ascii?q?UOwVHYV72KjrGSoAEIeReeygc1784JGZSWbueeMbEQt6bHCWeDferIj+P3jp?= =?us-ascii?q?xA/d2uv0uEe2pRGt1dBwsTMHfjLqVDLzM2dqbQG/Gnl616TzPKQwVpUiyybU?= =?us-ascii?q?N1JdQqrLbw5e/biR9sPW9e1DWz?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2B+DwBF2rZg/0tM69xCGB4BAQsSDEA?= =?us-ascii?q?JhHBWAQEBaYRIiQSHIwEBAQEBAQaBEi0DOAFUgyiGDxCGQYwhCwEBAQEBAQE?= =?us-ascii?q?BAQlBBAEBhFACgX8mOBMCBBUBAQEFAQEBAQEGAwGBBIV1hkUBBSMPASMzCxg?= =?us-ascii?q?CAiYCAiEoAQ0TBgIBARdagXwBglUDCSWpA4EygQGEZIJnDYJFgRAqjWpDfYE?= =?us-ascii?q?QgRUnD4I2Nj6CIIFgg1uCZASCJx52NjACfoERFC+efZwDW4MjmBWFQgUNBSW?= =?us-ascii?q?UbAiQZKUAj0kChUeBMjmBfU0fGYMkUBkOnHo0AQEBLzgCBgEJAQEDCYkTBwq?= =?us-ascii?q?BWF4BAQ?= X-IPAS-Result: =?us-ascii?q?A2B+DwBF2rZg/0tM69xCGB4BAQsSDEAJhHBWAQEBaYRIi?= =?us-ascii?q?QSHIwEBAQEBAQaBEi0DOAFUgyiGDxCGQYwhCwEBAQEBAQEBAQlBBAEBhFACg?= =?us-ascii?q?X8mOBMCBBUBAQEFAQEBAQEGAwGBBIV1hkUBBSMPASMzCxgCAiYCAiEoAQ0TB?= =?us-ascii?q?gIBARdagXwBglUDCSWpA4EygQGEZIJnDYJFgRAqjWpDfYEQgRUnD4I2Nj6CI?= =?us-ascii?q?IFgg1uCZASCJx52NjACfoERFC+efZwDW4MjmBWFQgUNBSWUbAiQZKUAj0kCh?= =?us-ascii?q?UeBMjmBfU0fGYMkUBkOnHo0AQEBLzgCBgEJAQEDCYkTBwqBWF4BAQ?= X-IronPort-AV: E=Sophos;i="5.83,241,1616428800"; d="scan'208";a="357721965" Received: from 220-235-76-75.dyn.iinet.net.au (HELO mail.infra.localdomain) ([220.235.76.75]) by icp-osb-irony-out2.iinet.net.au with ESMTP; 02 Jun 2021 09:13:45 +0800 Received: from localhost (mail.infra.localdomain [127.0.0.1]) by mail.infra.localdomain (Postfix) with ESMTP id 1485539711 for <gentoo-user@lists.gentoo.org>; Wed, 2 Jun 2021 09:13:45 +0800 (AWST) X-Virus-Scanned: amavisd-new at localdomain Received: from mail.infra.localdomain ([127.0.0.1]) by localhost (mail.infra.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIT7fIU9Jf_9 for <gentoo-user@lists.gentoo.org>; Wed, 2 Jun 2021 09:13:41 +0800 (AWST) Subject: Re: [gentoo-user] app-misc/ca-certificates To: gentoo-user@lists.gentoo.org References: <20210529030839.123d8526@melika.host77.tld> <YLHesQZxAxw+TftG@waltdnes.org> <5480288.DvuYhMxLoT@iris> <61db8745-dbb4-9c7e-80a9-6725905178c4@iinet.net.au> <CAC=wYCFDkSkHuCKF_GSUFVWZxVNiTNduH1HvFLQ3cmQYgrTcYg@mail.gmail.com> <CAGfcS_kDzG_uQyAw_oBv75eLsjQ-9k7yFnJntyE_k6Z72T80hQ@mail.gmail.com> From: William Kenworthy <billk@iinet.net.au> Message-ID: <10a7f73d-2d92-f24b-cc72-49af33db1aa4@iinet.net.au> Date: Wed, 2 Jun 2021 09:13:41 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 Precedence: bulk List-Post: <mailto:gentoo-user@lists.gentoo.org> List-Help: <mailto:gentoo-user+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-user.gentoo.org> X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <CAGfcS_kDzG_uQyAw_oBv75eLsjQ-9k7yFnJntyE_k6Z72T80hQ@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-AU X-Archives-Salt: 0a8ace37-96b5-4e24-a96c-321ffb94b891 X-Archives-Hash: 565fb11f030d91027a6df952f4aec8f5 On 1/6/21 9:29 pm, Rich Freeman wrote: > On Tue, Jun 1, 2021 at 7:59 AM Adam Carter <adamcarter3@gmail.com> wrote: >>> And another "wondering" - all the warnings about trusting self signed >>> certs seem a bit self serving. Yes, they are trying to certify who you >>> are, but at the expense of probably allowing access to your >>> communications by "authorised parties" (such as commercial entities >>> purchasing access for MITM access - e.g. certain router/firewall >>> companies doing deep inspection of SSL via resigning or owning both end >>> points). >> AFAIK in an enterprise MITM works by having a local CA added to the cert stores of the workstation fleet, and having that CA auto generate the certs for MITM. That didn't work with certificate pinning, but pinning has been deprecated. > So, I don't know all the ways that pinning is implemented, but if > you're talking about using MITM to snoop on enterprise devices on the > enterprise network I'd think that pinning wouldn't be an issue, > because you control the devices from cradle to grave. Just ensure the > pinned certificates are the ones that let you MITM the connections. > > Now, if your organization has some sort of guest network for > non-enterprise devices then pinning would obviously block MITM of > connections made by those devices. Really though I'm not sure you'd > want to be snooping stuff like this - it seems like more legal > headaches than it is worth. You want to sniff your OWN traffic for > IDS/etc or other unauthorized use, and since you're sniffing traffic > from devices you own you don't have the same legal issues (I won't say > no legal issues, but certainly monitoring your own devices is very > different from monitoring those you don't own). You shouldn't even be > allowing uncontrolled devices on those networks in the first place. > If you want to detect unauthorized devices MITM isn't really the best > solution - just use positive authentication of known-good devices > up-front and anything that doesn't pass that test is treated as a > threat and shouldn't even be able to send traffic. When discussing what traffic is looked at in an educational setting it looked like the system examined everything except mainline banking URL's For OpenVPN through a MiTM SSL proxy: Double wrap in SSL - outer one uses their cert so it does not fail that test - inner one uses your self signed cert for OpenVPN running on port 443 TCP. At the destination use the sslh multiplexor to divert SSL to stunnel/second sslh instance etc. to strip the SSL wrapping appropriately. Works using a combination of proxytunnel on the Windows side and stunnel on the linux end if needed - very flexible). There are are a few other enhancements for pinholing more difficult sites. Performance is entirely adequate for a road warrior setup when travelling (via a Raspberry Pi AP). I have had to get a lot more sophisticated than back in the day when httptunnel was all that was needed :) BillK