similar to: [security] Thunderbird vulnerable to MITM

On 08/23/2015 07:25 AM, Always Learning wrote: > > On Sat, 2015-08-22 at 08:05 -0700, Alice Wonder wrote: > >> Thunderbird has a MITM vulnerability with its otherwise rather groovy >> auto-configuration feature. > >> https://librelamp.com/FooBird#security >> >> has what I think would be the easiest solution while keeping the >> ability to

On Sat, 2015-08-22 at 08:05 -0700, Alice Wonder wrote: > Thunderbird has a MITM vulnerability with its otherwise rather groovy > auto-configuration feature. > https://librelamp.com/FooBird#security > > has what I think would be the easiest solution while keeping the > ability to auto-configure stuff. As for LibreSSL et al, perhaps you could mention all your concerns on

On Sun, 2015-08-23 at 07:57 -0700, Alice Wonder wrote: > I stopped using Fedora because as soon as it was stable it was end of > life and I was forced to install a new bleeding edge unstable version. I am 'conservative' too. Once something is working well I do not wish to change it unless there is a compelling conspicuous advantage. > I do not like bleeding edge for most

Hello, On Sat, 2015-08-22 at 08:05 -0700, Alice Wonder wrote: > Thunderbird has a MITM vulnerability with its otherwise rather groovy > auto-configuration feature. > > The problem is that it makes requests via HTTP to retrieve the auto > configuration information. > > This allows a black hat (e.g. the NSA) to modify the results sent to the > client, and the client has

Dear Damien, On Wed, Apr 19, 2023 at 9:55?AM Damien Miller <djm at mindrot.org> wrote: > > On Wed, 19 Apr 2023, Dmitry Belyavskiy wrote: > > > > While I'm sure this is good for RHEL/rawhide users who care about FIPS, > > > Portable OpenSSH won't be able to merge this. We explictly aim to support > > > LibreSSL's libcrypto as well as

Hi, We would like to use openssh in fips mode. It looks it is not provided as a configurable option through sshd_config, Are there plans to do incorporate such change. Do we have to change openssh code for now until the option is provided. If sshd is operating in fipsmode, does it provide additional errors/audits to indicate failures such as pair wise consistency failed during on of the sshd

Hello, My server with CentOS 6.8 just failed PCI scan, so I'm looking into vulnerable packages. PHP 5.3.3 have multiple vulnerabilities, some of them are fixed/patched or have some kind of workaround. But I can't find a way to fix this one. Red Hat state: under investigation. https://access.redhat.com/security/cve/cve-2016-4073 This CVE is 6 months old, and it doesn't look like it

On Wed, 19 Apr 2023, Dmitry Belyavskiy wrote: > > While I'm sure this is good for RHEL/rawhide users who care about FIPS, > > Portable OpenSSH won't be able to merge this. We explictly aim to support > > LibreSSL's libcrypto as well as openssl-1.1.x and neither supports the > > OSSL_PARAM_BLD API (neither does BoringSSL, though our support for that > >

Hi folks, I searched the list for LibreSSL and found only one mention of it! Has anyone gotten this working? I have it compiling no problem, but removing OpenSSL is another story of course. It seems to be compiled with FIPS support and of course there is no such thing in LibreSSL - that is something they tore out thanks, -Alan -- "Don't eat anything you've ever seen advertised

Is there any information available about what packages are being planned for the SCL? For example, will PHP 5.6 be made available & maintained? By "maintained" I mean kept up to date with back ported security patches and such. -- ----------------------------------------------- - Nick Bright - - Vice President of Technology - -

Hi all, Back in September 2018, I started a thread about implementing the X448 key exchange (see https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-September/037183.html). In February 2020, RFC 8731 (formally specifying X448 in SSH) has been finalized: https://www.ietf.org/rfc/rfc8731.txt. I thought I'd start this conversation up again to see if the interest level has

Hi, more or less a year ago Kurt Roeckx provided an initial port towards the OpenSSL 1.1 API [0]. The patch has been left untouched [1] and it has been complained about a missing compat layer of the new vs the old API within the OpenSSL library [2]. This is how I reconstructed the situation as of today and I am not aware of any progress in regard to the newer library within the OpenSSH project.

Dear Damien, On Wed, Apr 19, 2023 at 7:13?AM Damien Miller <djm at mindrot.org> wrote: > > On Tue, 18 Apr 2023, Norbert Pocs wrote: > > > Hi OpenSSH mailing list, > > > > I would like to announce the newly introduced patch in Fedora rawhide [0] > > for > > > > FIPS compliance efforts. The change will be introduced in an upcoming RHEL 9 > >

On Mon, 14 Nov 2016, Jakub Jelen wrote: > Thank you for the comments. I understand the upstream directions and > that the OpenSSL step is not ideal. The distros will probably have to > carry these patches until the changes will settle down a bit. AFAIK Red Hat employs at least one OpenSSL maintainer. What is their view on this situation? > Other possible solution we were discussing

On Tue, 18 Apr 2023, Norbert Pocs wrote: > Hi OpenSSH mailing list, > > I would like to announce the newly introduced patch in Fedora rawhide [0] > for > > FIPS compliance efforts. The change will be introduced in an upcoming RHEL 9 > > version. > > The patch targets OpenSSL support of OpenSSH, specifically the usage of > > old low level API. The new

On 08/03/2016 05:20 PM, Alice Wonder wrote: > On 08/03/2016 05:11 PM, Alice Wonder wrote: >> I'm having a major frustration with curl. >> >> When building curl, if libssl.so.10 is present the curl binary WILL link >> against it. > > *snip* > > Go ahead and ldd on the CentOS curl binary and library - you will see > openssl linked even though the spec

Hi, One of our users who is running an OS (I think it's the latest beta macOS 10.14.1) with ssh version "OpenSSH_7.8p1, LibreSSL 2.7.3" is unable to use our user SSH RSA certificates to authenticate to our servers (which are running "OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017"). We see this error on the client side: debug1: kex_input_ext_info:

Hi OpenSSH mailing list, I would like to announce the newly introduced patch in Fedora rawhide [0] for FIPS compliance efforts. The change will be introduced in an upcoming RHEL 9 version. The patch targets OpenSSL support of OpenSSH, specifically the usage of old low level API. The new OpenSSL version 3.0 introduces a FIPS module (going through FIPS 140-2 validation and to be FIPS 140-3

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

http://marc.info/?l=postfix-users&m=129952854117623&w=2 Dovecot doesn't have this bug. It discards all buffered data when STARTTLS command runs. (Why do I think I've heard about this bug before? Or at least the same type of way to exploit it? Maybe there was another similarly exploitable bug.)