similar to: CentOS-announce Digest, Vol 143, Issue 1

CentOS Errata and Security Advisory 2017:0001 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-0001.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: dc28c95448c5a8315f1a6546daf679aa59e0679ec1b48bfba148627ea6f48ff6 ipa-admintools-4.4.0-14.el7.centos.1.1.noarch.rpm

http://bugzilla.mindrot.org/show_bug.cgi?id=143 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-01-07 17:28

huh? Not sure how this got put in the stable queue, but this probably should be dropped. this was prepatory work for some MST functionality that got added recently, not a fix. On Tue, 2019-12-10 at 16:04 -0500, Sasha Levin wrote: > From: Lyude Paul <lyude at redhat.com> > > [ Upstream commit ac0de16a38a9ec7026ca96132e3883c564497068 ] > > Currently, we enable hotplug

4.14-stable review patch. If anyone has any objections, please let me know. ------------------ [ Upstream commit 571d0563c8881595f4ab027aef9ed1c55e3e7b7c ] The first argument to WARN_ONCE() is a condition. Fixes: 5800dc5c19f3 ("x86/paravirt: Fix spectre-v2 mitigations for paravirt guests") Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> Signed-off-by: Thomas

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

Hi all, Is there a way to disable the TLS support provided by Dovecot on port 143? I'd like to run SSL on 993, so as far as I can tell I can't use ssl_disable, since the will disable SSL. I'm looking for the equivalent of an ssl_disable_tls setting. Thanks much, Jackie --- Jackie Hunt ACNS

I'm testing my new dovecot server with Thundirbird I can have it working on port 143 with STARTTLS, or on port 993 with SSL/TLS my uderstanding is that on 993 I get encrypted 'password and mail transfer' (yes ?) so what happens if I use 143 with STARTTLS, is that equivalent to port 993 if STARTTLS is used ? thanks for any insights.. -- Voytek

On 08/21/2017 07:28 AM, voytek at sbt.net.au wrote: > is there a 'preferred way'? should I tell users to use 143 over 993 ? or > 993 over 143? or? There is no concrete answer. There are various opinions and feelings about this. The opinion againt 993/995 is that these are not standard ports, and there is no need to allocate new ports for the secure version of each protocol since we

On Mon, 21 Aug 2017, Sebastian Arcus wrote: > > On 21/08/17 10:37, Gedalya wrote: > > On 08/21/2017 07:28 AM, voytek at sbt.net.au wrote: > > > is there a 'preferred way'? should I tell users to use 143 over 993 ? or > > > 993 over 143? or? > > There is no concrete answer. There are various opinions and feelings about > > this. > > The

On Mon, 21 Aug 2017, Sebastian Arcus wrote: > On 21/08/17 13:39, Robert Wolf wrote: > > > > On Mon, 21 Aug 2017, Sebastian Arcus wrote: > > > > > > > > On 21/08/17 10:37, Gedalya wrote: > > > > On 08/21/2017 07:28 AM, voytek at sbt.net.au wrote: > > > > > is there a 'preferred way'? should I tell users to use 143 over

On 21/08/17 22:18, Joseph Tam wrote: > > Lest anyone think STARTTLS MITM doesn't happen, > > https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/ > > Not only for security, I prefer port 993/995 as it's just plain simpler > to initiate SSL from the get-go rather than to do some handshaking that > gets you to the same

Gary <lists at lazygranch.com> writes: > If I read this correctly, starttls will fail due to the MITM attack. > That is the client knows security has been compromised. I'm not sure what you man by "fail". STARTTLS is prone to MITM attacks if a client has not been configured to refuse non-STARTTLS/SSL sessions. For clients that will allow both secured and plaintext

On Tue, 22 Aug 2017, Ivan Warren wrote: > Le 8/22/2017 ? 10:03 AM, Robert Wolf a ?crit?: > > > > WRONG!!! The email is stored plain-text on the first server and then it can > > be > > sent to other few MX servers over plain-text connection. I.e. encrypted > > connection does not protect emails, but the authentication credentials. > > > > > Indeed.

On Tue, 22 Aug 2017, Aki Tuomi wrote: > else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you > have enabled something like cram-md5. Hi, exactly, this is the reason, why plain-text is still needed. You don't need encryption for authentication, if you have secure authentication. Without knowing original password, the MITM cannot generate correct hash for login, so

> On 25/05/2020 21:48 mj <lists at merit.unu.edu> wrote: > > > Hi, > > I am trying to find a nice way to identify dovecot clients that are > still configured to use port 143 to connect to our mailserver, from the > dovecot logs. > I would then ask them to move over to 993, and finally disable port 143 > altogether. > > When looking at the dovecot

On 26 May 2020 4:48:51 AM AEST, mj <lists at merit.unu.edu> wrote: >I would then ask them to move over to 993, and finally disable port 143 >altogether. > jumping here with a question, if I use 143 with STARTTLS, and, force TLS/SSL in configuration, that's equivalent from security POV, isn't it? and, same for 110 STARTTLS? Or am I missing something? thanks, V -- Sent

Hi, On 26.05.20 09:21, mj wrote: > One doubt I had: "disable_plaintext_auth = yes" sounds as if only the > authentication part is secured, and the rest is kept plain text, whereas > with 993/SSL, *everything* would be encrypted? > > Or am I missing something? (then perhaps someone can point it out?) here you can read the details:

On 2020-05-26, mj <lists at merit.unu.edu> wrote: > Hi, > > On 25/05/2020 23:04, Voytek wrote: >> jumping here with a question, if I use 143 with STARTTLS, and, force >> TLS/SSL in configuration, that's equivalent from security POV, isn't >> it? and, same for 110 STARTTLS? Or am I missing something? > Interesting point, after some googling, I think you

Thanks to all who participated in the interesting discussion. It seems my initial thought might have been best after all, and discontinuing port 143 might be the safest way proceed. Thanks again, valuable insights! MJ On 5/29/20 11:48 AM, Jean-Daniel wrote: > > >> Le 29 mai 2020 ? 11:17, Stuart Henderson <stu at spacehopper.org >> <mailto:stu at

> Le 31 mai 2020 ? 06:09, Peter <peter at pajamian.dhs.org> a ?crit : > > On 29/05/20 11:27 pm, mj wrote: >> Thanks to all who participated in the interesting discussion. >> It seems my initial thought might have been best after all, and discontinuing port 143 might be the safest way proceed. > > Yes and no. Some of the attack vectors mentioned are not