similar to: yum/RPM and Trust on First Use

On 12/20/2015 12:16 PM, John R Pierce wrote: > On 12/20/2015 4:26 AM, Ned Slider wrote: >> Unless I'm mistaken RPM in el5 does not support the https protocol. > > did you mean Yum ? rpm is just a file format for packages, and a > package installer program, its yum that does the network operations to > fetch the packages, and as far as I understand it uses libcurl, so it

On 12/15/2015 07:05 PM, Alice Wonder wrote: > The first time yum installs a package, it asks to import the GPG key > used to sign the packages. Most people accept without validating the key. While that is true, it is important to note that yum will only import keys that are already installed on disk, in /etc/pki/rpm-gpg. Which means that only keys that were *previously* installed from a

On 12/19/2015 02:12 AM, Gordon Messmer wrote: > On 12/15/2015 07:05 PM, Alice Wonder wrote: >> The first time yum installs a package, it asks to import the GPG key >> used to sign the packages. Most people accept without validating the key. > > While that is true, it is important to note that yum will only import > keys that are already installed on disk, in

On Sun, 2015-12-20 at 12:44 -0800, Alice Wonder wrote: > RPM has ability to install a package over the network. > > rpm -i ftp://example.org/foo-2.2.noarch.rpm Thanks for the new knowledge. > The point I'm trying to make though is that yum could benefit from > the ability to verify the fingerprint in a key it is importing > matches a DNS query for the user and domain

On 12/20/2015 10:05 AM, Gordon Messmer wrote: > On 12/20/2015 04:26 AM, Ned Slider wrote: >> Unless I'm mistaken RPM in el5 does not support the https protocol. > > In that case, users should use curl or wget to retrieve the rpm over > https before installing it. Yes, but I've run into instance where curl does not work for https - for example I believe if ECDSA TLS

On Wed, Apr 27, 2016 at 1:04 AM, Alice Wonder <alice at domblogger.net> wrote: > Not with a smtp that enforces DANE. I'm aware of how DANE works. The only problem is no MTA outside of Postfix implements it. You can thank the hatred of DNSSEC for that. Brandon Vincent

On 20/12/15 10:28, Gordon Messmer wrote: > On 12/19/2015 09:49 AM, Alice Wonder wrote: >> >> With third party repositories the key and configuration file is often >> distributed separately. That's the potential attack vector for trojan >> keys. > > Examples? > > All of the notable repositories that I'm aware of publish an > x-release.rpm that

On 04/27/2016 12:30 AM, James Hogarth wrote: *snip* > > Unless you have a very specific requirement for a very bleeding edge > feature it's fundamentally a terrible idea to move away from the > distribution packages in something as exposed as a webserver ... I use to believe that. However I no longer. First of all, advancements in TLS happen too quickly. The RHEL philosophy of

Hi, I found a small issue with DNSSEC validation of SSHFP lookups. (For reference I used OpenSSH 6.8p1 on FreeBSD 10.1). The issues is that when DNSSEC valiation fails, ssh displays a confusing message to the user. When DNSSEC validation of a SSHFP record fails, ssh presents the user with "Matching host key fingerprint found in DNS. "Are you sure you want to continue connecting

On 04/27/2016 07:50 PM, Alice Wonder wrote: > On 04/27/2016 12:41 AM, Alice Wonder wrote: >> On 04/27/2016 12:30 AM, James Hogarth wrote: >> *snip* >>> >>> Unless you have a very specific requirement for a very bleeding edge >>> feature it's fundamentally a terrible idea to move away from the >>> distribution packages in something as exposed

Le 23/05/2016 à 14:46, Rowland penny a écrit : > On 23/05/16 12:56, Sam wrote: >> > > It looks like your problems have nothing to do with dhcp, one problem > appears to be related to dnssec: > > May 23 10:52:27 S4 named[2162]: validating @0x7eff24296b50: > choices.truste.com A: no valid signature found > > If you have 'dnssec-validation yes;' in

https://bugzilla.mindrot.org/show_bug.cgi?id=2119 Bug ID: 2119 Summary: SSHFP with DNSSEC ? no trust anchors given, validation always fails Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component:

On Wed, Apr 27, 2016 at 12:50 AM, Alice Wonder <alice at domblogger.net> wrote: > That is the only reliable way to avoid MITM with SMTP. Except I can just strip STARTTLS and most MTAs will continue to connect. Brandon Vincent

Hi, ??? Anyone else had any issues with CentOS 6.10 bind DNS server issues this afternoon. At 16:26 (GMT) had alerts for DNS failures against our CentOS 6.10 bind DNS servers from our monitoring system. Sure enough DNS requests via the server was failing, checking the named.log showed dnssec issues; 25-Mar-2020 16:26:10.285 dnssec: info: validating @0xb48b17c0: push.services.mozilla.com

Hi, I submitted a patch back in November of 2009 to add local validation of DNSSEC record to openssh. I recent updated the patch for 5.8, and figured I do a little marketing while I'm at it. :-) Someone had previously submitted a patch which simply trusted the AD bit in the response, which is susceptible to spoofing by anyone who can inject packets between the resolver and the client. Our

I'm interested in using SMB encryption to connect over untrusted networks. I see that I can enable it in samba with 'smb encrypt = ...' which is great, and I'm seeing posts from Microsoft (like this one: https://technet.microsoft.com/en-us/library/dn551363(v=ws.11).aspx) bragging about how it can detect man-in-the-middle attacks. Can anyone point me at the basic details of how

If I read this correctly, starttls will fail due to the MITM attack. That is the client knows security has been compromised. Using SSL/TLS, the MITM can use SSL stripping. Since most Postifx conf use "may" for security, the message would go though unencrypted. Correct??? Is there something to enable for perfect forward security with starttls? ? Original Message ? From: s.arcus at

On Sun, 4 Oct 2020, Christoph Anton Mitterer wrote: > On Sat, 2020-10-03 at 19:44 +1000, Damien Miller wrote: > > Otherwise, feel free to ask me anything. > > Was it ever considered that the feature itself could be problematic, > security-wise? Of course we considered this. > I see at least two candidates: > - It's IMO generally a bad idea to distribute

I have been running openSSH 7.4p1 for a while now. When I upgraded to 7.5 a year or so ago I ran into the problem listed in this bug report: Bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218472 The release notes for 7.6 release notes indicate that the fix patch was included: https://www.openssh.com/txt/release-7.6 I tried 7.6 and I still cannot connect without a prompt wondering

On Wed, May 17, 2017 at 2:46 AM, Damien Miller <djm at mindrot.org> wrote: > On Mon, 15 May 2017, Adam Eijdenberg wrote: >> https://github.com/golang/go/issues/20273 >> >> By default they are looking for a principal named "host:port" inside >> of the certificate presented by the server, instead of just looking >> for the host as I believe OpenSSH