Re: TLS warning
Telus is so broken in several ways. I complain and the friendly support person acts as if nothing is wrong. As I understand it, you need to be sending to their SMTP server from 'within their network'. Either on their LTE or on their home/business internet service. So when you leave your wifi on and it connects somewhere, perhaps in a restaurant, then your outgoing email fails auth. And the auth on LTE is by IMEI, not by password, so if someone can spoof that... I suspect that is not difficult? Telus is not as big as Microsoft, agreed, but it is one third of our wireless industry, so it is big. Cheers -- Rick On May 25, 2017 3:26:34 PM EDT, D'Arcy Cainwrote: >On 2017-05-25 03:20 PM, li...@lazygranch.com wrote: >> Right from the Telus website : >> -- >> "Clear the Requires a secure connection (SSL) check box" >> >> "Authenticate using: Clear text" >> >> >http://business.telus.com/en/business/support/global/how-to/how-to-set-up-your-email-on-any-computer >> --- >> >> Seriously Canada? And this is the advice to their business customers. > >Hey! Canada's a big place. Don't blame all of us for one company's >policies. We don't blame all of you for Microsoft. > >-- >D'Arcy J.M. Cain >System Administrator, Vex.Net >http://www.Vex.Net/ IM:da...@vex.net >VoIP: sip:da...@vex.net -- Sorry for being brief. Alternate email is rickleir at yahoo dot com
Re: TLS warning
On 2017-05-25 03:20 PM, li...@lazygranch.com wrote: Right from the Telus website : -- "Clear the Requires a secure connection (SSL) check box" "Authenticate using: Clear text" http://business.telus.com/en/business/support/global/how-to/how-to-set-up-your-email-on-any-computer --- Seriously Canada? And this is the advice to their business customers. Hey! Canada's a big place. Don't blame all of us for one company's policies. We don't blame all of you for Microsoft. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
Re: TLS warning
Right from the Telus website : -- "Clear the Requires a secure connection (SSL) check box" "Authenticate using: Clear text" http://business.telus.com/en/business/support/global/how-to/how-to-set-up-your-email-on-any-computer --- Seriously Canada? And this is the advice to their business customers. Original Message From: Phil Stracchino Sent: Thursday, May 25, 2017 9:31 AM To: postfix-users@postfix.org Subject: Re: TLS warning On 05/25/17 12:28, James B. Byrne wrote: > Yes, I cannot image why members of the so called 'five-eyes' > consortium would not actively promote signal security among their > populations. > > Must be an oversight. Or a lack thereof -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: TLS warning
On 05/25/17 12:28, James B. Byrne wrote: > Yes, I cannot image why members of the so called 'five-eyes' > consortium would not actively promote signal security among their > populations. > > Must be an oversight. Or a lack thereof -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: TLS warning
On Thu, May 25, 2017 05:23, li...@lazygranch.com wrote: > > > This paper is a good read on email security. It goes into the various > means that a man in the middle can reduce security, one of which is > enabled by selecting opportunistic encryption. (Of which in all > practicality you don't have a choice if you want maximum > compatibility. I'm amazed at the lack of encryption in first world > countries like Canada or the UK.) > Yes, I cannot image why members of the so called 'five-eyes' consortium would not actively promote signal security among their populations. Must be an oversight. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Re: TLS warning
> On May 25, 2017, at 5:23 AM, li...@lazygranch.com wrote: > > "Neither Snow Nor Rain Nor MITM . . . > An Empirical Analysis of Email Delivery Security" > https://jhalderm.com/pub/papers/mail-imc15.pdf > Video by one of the authors. > https://www.youtube.com/watch?v=_aogXeTbERs It is a good academic study, but like many such efforts, it implicitly compares SMTP with HTTPS, but the proper comparison is with the combination of HTTP and HTTPS. Take a look at: https://www.google.com/transparencyreport/saferemail/ By now ~85-88% email inbound to Gmail is TLS encrypted in transit. The fraction of Web traffic that uses HTTPS is in recent reports only ~50%. If we're talking SMTP security (and not end-to-end encryption which remains deeply impractical for most use-cases), then implement DANE, but make sure you understand the operational responsibilities, DANE is not deploy and forget, key rotation must be handled correctly and consistently: https://dane.sys4.de/common_mistakes http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 Ideally via robust hooks that automatically update the relevant DNS entries (as required) as part of the key rotation process. -- Viktor.
Re: TLS warning
> On May 25, 2017, at 5:23 AM, li...@lazygranch.com wrote: > > Given the email issues in recent political campaigns, I'm seeing a > number of articles suggesting setting up DMARC for quarantine. DMARC is an abuse of the IETF process (informational RFC) to promote and deploy a deeply flawed specification. It should never have been deployed outside domains that only do "transactional email" subject to phishing like paypal.com. Yahoo deployed it despite the resulting breakage to everyone else, because it lowered their abuse desk costs. I neither deploy nor check DMARC. It is a broken design. -- Viktor.
Re: TLS warning
On Thu, 25 May 2017 03:02:39 -0400 Rick Leirwrote: > > > On 2017-05-25 02:31 AM, Philip Paeps wrote: > > On 2017-05-24 14:54:34 (+0200), Bastian Blank > > wrote: > >> On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com > >> wrote: > >>> You shouldn't be accepting sslv3 due to the poodle attack. > >>> https://en.m.wikipedia.org/wiki/POODLE > >> > >> Please explain how exactly SMTP is exploitable using POODLE? > > > > There are other good reasons to disable SSLv3. But POODLE is a > > distraction in the context of SMTP. > In the context of a SASL login to send outgoing email, is it still a > distraction? > > How about dovecot, logging in to receive email and clean up my inbox? > > As recommended by lazyG, > > http://disablessl3.com/ > > > > > In general though, when it comes to SMTP, any encryption is better > > than none. And opportunistic encryption is the way to go. Read > > RFC 7435: > > > > https://tools.ietf.org/html/rfc7435 > Thanks! > > > > Philip > > > This paper is a good read on email security. It goes into the various means that a man in the middle can reduce security, one of which is enabled by selecting opportunistic encryption. (Of which in all practicality you don't have a choice if you want maximum compatibility. I'm amazed at the lack of encryption in first world countries like Canada or the UK.) "Neither Snow Nor Rain Nor MITM . . . An Empirical Analysis of Email Delivery Security" https://jhalderm.com/pub/papers/mail-imc15.pdf Video by one of the authors. https://www.youtube.com/watch?v=_aogXeTbERs Given the email issues in recent political campaigns, I'm seeing a number of articles suggesting setting up DMARC for quarantine. Most recent: http://www.prnewswire.com/news-releases/bishop-fox-research-finds-98-of-the-top-million-internet-domains-are-potentially-vulnerable-to-email-spoofing-300461861.html Specifically "First, companies must safeguard their company's domain by checking the company's DNS records for SPF and DMARC. Make sure that the company's domain has a properly configured SPF record and a DMARC record with a policy of quarantine or reject. Then, use Spoofcheck to check if the domain is sufficiently protected." Where http://spoofcheck.bishopfox.com/#!/ isn't exactly rocket science. It just reads your DMARC.
Re: TLS warning
On 2017-05-25 02:31 AM, Philip Paeps wrote: On 2017-05-24 14:54:34 (+0200), Bastian Blankwrote: On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com wrote: You shouldn't be accepting sslv3 due to the poodle attack. https://en.m.wikipedia.org/wiki/POODLE Please explain how exactly SMTP is exploitable using POODLE? There are other good reasons to disable SSLv3. But POODLE is a distraction in the context of SMTP. In the context of a SASL login to send outgoing email, is it still a distraction? How about dovecot, logging in to receive email and clean up my inbox? As recommended by lazyG, http://disablessl3.com/ In general though, when it comes to SMTP, any encryption is better than none. And opportunistic encryption is the way to go. Read RFC 7435: https://tools.ietf.org/html/rfc7435 Thanks! Philip
Re: TLS warning
On 2017-05-24 14:54:34 (+0200), Bastian Blankwrote: On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com wrote: You shouldn't be accepting sslv3 due to the poodle attack. https://en.m.wikipedia.org/wiki/POODLE Please explain how exactly SMTP is exploitable using POODLE? There are other good reasons to disable SSLv3. But POODLE is a distraction in the context of SMTP. In general though, when it comes to SMTP, any encryption is better than none. And opportunistic encryption is the way to go. Read RFC 7435: https://tools.ietf.org/html/rfc7435 Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: TLS warning
Viktor, LazyG This is not nonsense, as I learned something from it. Now I will go and check whether it is enabled. And thanks for mentioning foundations and family etc. That is also useful. Maybe we should be a bit more polite to other folks in the list, we are mostly 'in the same boat'. Cheers --- Rick On May 24, 2017 12:26:32 PM EDT, Viktor Dukhovniwrote: > >> On May 24, 2017, at 5:41 AM, li...@lazygranch.com wrote: >> >> You shouldn't be accepting sslv3 due to the poodle attack. >> >> https://en.m.wikipedia.org/wiki/POODLE >> >> A search should indicate what to change to reject sslv3. >> >> Of course there still could be other things that need fixing. ;-) > >Please don't distract people asking questions with nonsense. > >There is no evidence the OP has SSLv3 enabled. The SSLv3 >protocol is the foundation on which TLS 1.0, 1.1 and 1.2 >(and to a much lesser extent TLS 1.3) are built. All >these protocols share the underlying record layer and >alert processing code. When OpenSSL logging reports >an error from an "ssl3" function, the actual protocol >in use could be any of the family of protocols that >are based on SSL 3.0. > >-- > Viktor. -- Sorry for being brief. Alternate email is rickleir at yahoo dot com
Re: TLS warning
> On May 24, 2017, at 5:41 AM, li...@lazygranch.com wrote: > > You shouldn't be accepting sslv3 due to the poodle attack. > > https://en.m.wikipedia.org/wiki/POODLE > > A search should indicate what to change to reject sslv3. > > Of course there still could be other things that need fixing. ;-) Please don't distract people asking questions with nonsense. There is no evidence the OP has SSLv3 enabled. The SSLv3 protocol is the foundation on which TLS 1.0, 1.1 and 1.2 (and to a much lesser extent TLS 1.3) are built. All these protocols share the underlying record layer and alert processing code. When OpenSSL logging reports an error from an "ssl3" function, the actual protocol in use could be any of the family of protocols that are based on SSL 3.0. -- Viktor.
Re: TLS warning
The industry/market/whatever decided the best practice was to stop using ssl3. This wasn't my call. Postfix conf file instructions here as well as more information why to stop using it. http://disablessl3.com/ Original Message From: Bastian Blank Sent: Wednesday, May 24, 2017 5:55 AM To: postfix-users@postfix.org Subject: Re: TLS warning Hi Lists On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com wrote: > You shouldn't be accepting sslv3 due to the poodle attack. > https://en.m.wikipedia.org/wiki/POODLE Please explain how exactly SMTP is exploitable using POODLE? Bastian -- Worlds are conquered, galaxies destroyed -- but a woman is always a woman. -- Kirk, "The Conscience of the King", stardate 2818.9
Re: TLS warning
Hi Lists On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com wrote: > You shouldn't be accepting sslv3 due to the poodle attack. > https://en.m.wikipedia.org/wiki/POODLE Please explain how exactly SMTP is exploitable using POODLE? Bastian -- Worlds are conquered, galaxies destroyed -- but a woman is always a woman. -- Kirk, "The Conscience of the King", stardate 2818.9
Re: TLS warning
You shouldn't be accepting sslv3 due to the poodle attack. https://en.m.wikipedia.org/wiki/POODLE A search should indicate what to change to reject sslv3. Of course there still could be other things that need fixing. ;-) Original Message From: Rick Leir Sent: Wednesday, May 24, 2017 2:31 AM To: postfix-users@postfix.org Subject: TLS warning Hi All Should this TLS warning worry me? cheers -- Rick Warnings smtpd (total: 1) 1 TLS library problem: error:14094416:SSL routines:SSL3_READ_BYTE... mail.log: May 23 11:35:42 myHostName postfix/smtpd[6619]: connect from sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208] May 23 11:35:43 myHostName postfix/smtpd[6619]: SSL_accept error from sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208]: 0 May 23 11:35:43 myHostName postfix/smtpd[6619]: warning: TLS library problem: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1262:SSL alert number 46: May 23 11:35:43 myHostName postfix/smtpd[6619]: lost connection after STARTTLS from sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208] May 23 11:35:43 myHostName postfix/smtpd[6619]: disconnect from sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208] May 23 11:35:43 myHostName postfix/postscreen[6613]: CONNECT from [66.163.186.208]:33240 to [myIPv4]:25 May 23 11:35:43 myHostName postfix/postscreen[6613]: PASS OLD [66.163.186.208]:33240 May 23 11:35:43 myHostName postfix/smtpd[6619]: connect from sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208] May 23 11:35:43 myHostName postfix/smtpd[6619]: 6C9CF41E45: client=sonic310-27.consmr.mail.ne1.yahoo.com[66.163.186.208] # apt-cache depends postfix Depends: libsasl2-2 Depends: libssl1.0.0 Depends: ssl-cert Suggests: sasl2-bin Suggests: libsasl2-modules # apt-cache madison libsasl2-2 libsasl2-2 | 2.1.25.dfsg1-17build1 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages cyrus-sasl2 | 2.1.25.dfsg1-17build1 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty/main Sources # apt-cache madison libssl1.0.0 libssl1.0.0 | 1.0.1f-1ubuntu2.22 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages libssl1.0.0 | 1.0.1f-1ubuntu2.22 | http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages libssl1.0.0 | 1.0.1f-1ubuntu2 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages openssl | 1.0.1f-1ubuntu2 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty/main Sources openssl | 1.0.1f-1ubuntu2.22 | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main Sources openssl | 1.0.1f-1ubuntu2.22 | http://security.ubuntu.com/ubuntu/ trusty-security/main Sources