[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The netsec thread
From: |
Robert Pluim |
Subject: |
Re: The netsec thread |
Date: |
Mon, 23 Jul 2018 10:17:52 +0200 |
Jimmy Yuen Ho Wong <address@hidden> writes:
>> And, as I've said before,
>> `paranoid' should stay.
>>
>
> Eli's use case has already been taken cared of by
> `nsm-trust-local-network`. `paranoid has been aliased to `high for
> backward compatibility.
>
> Robert do you still object to removing the `paranoid level? I've
> removed that prompt that askes for permission on every TLS connection
> due to crying-wolf effect.
As Iʼve said before: I donʼt think many people need to be prompted
every time a TLS connection is set up from emacs to a host thatʼs
never been seen before, but I do, as I need to inspect the connection
parameters. Yes itʼs annoying, but I can live with self-imposed
annoyance.
> If there isn't an objection from people who've found use for it, I'd
> really like to try without 'paranoid on master later before declaring
> it insufficient.
I guess I could always add my own function into 'high, but Iʼd prefer
it if it was available by default.
>>> +(defun nsm-should-check (host)
>>> + "Determines whether NSM should check for TLS problems for HOST.
>>> +
>>> +If `nsm-trust-local-network' is or returns non-nil, and if the
>>> +host address is a localhost address, a machine address, a direct
>>> +link or a private network address, this function returns
>>> +nil. Non-nil otherwise."
>>
>> What do you mean by "machine address"? The MAC address? If you mean
>> IP address, it's perfectly valid to have TLS on a non-named IP
>> address. 1.0.0.1 does that for DNS over HTTPS last I heard, and
>> that's definitely a service you should verify, well, everything on.
>>
Iʼm a bit dubious about the whole 'nsm-trust-local-network' stuff. nsm
already stores per-host settings, so why the need to check for RFC
1918 addresses? Besides, I can easily set things up so that Iʼm using
RFC1918 addresses, but the packets would definitely not be going over
what you'd think of as a 'local' or 'private' network.
Iʼd thought this was going to be something like 'trust this subnet',
which I can see people wanting, although Iʼd recommend against them
using. That would require that nsm-should-check pass the host to the
user-specified nsm-trust-local-network function (or you define a
'nsm-trusted-by-default-networks' variable).
> I mean 0.0.0.0/8. I'm not sure what the proper name is or if I even
> need to deal with it. What do you think?
If you mean localhost, then you have:
(or
;; (0.x.x.x) this machine
(eq (aref address 0) 0)
;; (127.x.x.x) localhost
(eq (aref address 0) 0))
where that second eq should check against 127, I think. I can think of
no situation in which 0.0.0.0/8 would be something you need to check
against (nor can I see how you'd ever see such a value).
Robert
- Re: The netsec thread, (continued)
- Re: The netsec thread, Lars Ingebrigtsen, 2018/07/24
- Re: The netsec thread, Andy Moreton, 2018/07/24
- Re: The netsec thread, Andy Moreton, 2018/07/24
- Re: The netsec thread, Noam Postavsky, 2018/07/24
- Re: The netsec thread, Jimmy Yuen Ho Wong, 2018/07/24
- Re: The netsec thread, Lars Ingebrigtsen, 2018/07/24
- Re: The netsec thread, Andy Moreton, 2018/07/24
- Re: The netsec thread, Eli Zaretskii, 2018/07/23
- Re: The netsec thread, Lars Ingebrigtsen, 2018/07/22
- Re: The netsec thread, Jimmy Yuen Ho Wong, 2018/07/22
- Re: The netsec thread,
Robert Pluim <=
- Re: The netsec thread, Jimmy Yuen Ho Wong, 2018/07/23
- Re: The netsec thread, Robert Pluim, 2018/07/23
- Re: The netsec thread, Lars Ingebrigtsen, 2018/07/23
- Re: The netsec thread, Jimmy Yuen Ho Wong, 2018/07/23
- Re: The netsec thread, Noam Postavsky, 2018/07/23
- Re: The netsec thread, Lars Ingebrigtsen, 2018/07/23
- Re: The netsec thread, Eli Zaretskii, 2018/07/23
- Re: The netsec thread, Jimmy Yuen Ho Wong, 2018/07/23
- Re: The netsec thread, Robert Pluim, 2018/07/23
- Re: The netsec thread, Jimmy Yuen Ho Wong, 2018/07/23