Re: [mailop] [EXTERNAL] Disabling TLS 1.0 and 1.1 for MTA to MTA communication
On 4 Aug 2022 15:29:52 -0400, John Levine via mailop wrote: >If my logs are at all typical, there are no large entities still using >TLS 1.0. I see a lot of spambots, some compromised VPS at the usual >suspects like OVH, one well-known IETFer who knows that he needs to >update his mail server, and Team Cymru who should be embarassed. Of the 1208 SMTP sessions using TLS during the past seven days, 35 were 1.0. Of that, 10 were from an email list about an open-source product, 8 were the mail client I am using at this moment (Forté Agent). The others appear to be spambots. mdr -- Human beings are perhaps never more frightening than when they are convinced beyond doubt that they are right. -- Laurens Van Der Post, The Lost World of The Kalahari ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google still using SHA1 (and forcing it)?
On 04/08/2022 16:12, Chris Adams via mailop wrote: I ran into an issue at $DAYJOB where we had a hard-coded TLS version and ciphersuite set connecting to Google (specifically aspmx.l.google.com). The problem turned out to be a library upgrade had disabled SHA1, so the TLS hello handshake failed. Here's an example to reproduce it with gnutls-cli: $ gnutls-cli --priority=NORMAL:-VERS-ALL:+VERS-TLS1.2:-MAC-ALL:+SHA384:+SHA256 --starttls-proto=smtp aspmx.l.google.com:25 Processed 148 CA certificate(s). Resolving 'aspmx.l.google.com:25'... Connecting to '2607:f8b0:4002:c08::1a:25'... *** Fatal error: A TLS fatal alert has been received. *** Received alert [40]: Handshake failed If you add ":+SHA1" at the end of the priority string, it connects successfully (and uses SHA1). Oddly, if I nmap scan what ciphers appear to work with TLSv1.2, there are SHA256 and SHA384 ciphers available (and were in our hard-coded list). From an nmap: | TLSv1.2: | ciphers: | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A So is there a bug on Google's side forcing SHA1, or am I missing something (which is quite possible, getting into obscure bits of TLS does trip me up)? SHA1 is used for AEAD algorithms (such as ChaCha-Poly/AES-GCM) merely as a key derivation algorithm (HKDF), for CBC modes SHA1 is also used for integrity checks (HMAC) [1]. The usage of sha1 is perfectly secure in the both cases (but not for certificates signatures, of course!). The choice between SHA/SHA256/SHA384 is based on the requirements to the transport constructs, e.g. keys lengths adjustments. [1]: https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_integrity ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What to do with a look-alike domain used in phishing
A fellow named Mike Andrews used to offer to take over domains once used by, or likely to be used be, spam and malware. I had once grabbed an expired domain used by a spammer network, and I was glad to transfer it over to him rather than continue to pay the annual fee myself. On Mon, Jul 18, 2022 at 10:29:06AM +0200, Tobias Fiebig via mailop wrote: > Heho, > ~a year ago I registered a (by then) unregistered look-alike domain for a > major European hoster, as I was receiving rather good spear-phishing from it, > and it was, well, unregistered. (The domain is hetzners.de ). > > I setup DMARC p=reject and SPF -all, and let it be. Now, the domain keeps > sitting around; Thing is, that dereg would most likely lead to more spam > falling out of the domain again (or it being actually registered by some > spammer), which is rather not so nice to the Internet as a whole. The hoster > is not interested in receiving it from me (free of charge etc.; Offered to > just send them the authcode). > > Now, what can I ethically do with the domain? I would kind of prefer it going > to some org. that actually makes an effort in drying out domains used like > this; Does somebody have a suggestion/contact whom to ask? > > With best regards, > Tobias -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
