While dealing with the SHA-1 sunsetting process I encountered a problem with some certificates from StartSSL/StartCom that may lead Chrome to raise warnings or even errors on websites with updated SHA-2-only chains (at least on Microsoft Windows clients).
On the Integration of pmacct with ElasticSearch and Kibana post a user (Xentoo) asked how to display geographic information provided by pmacct on a Kibana 4 map using pmacct-to-elasticsearch.
After reading Antonio Prado’s Reverse DNS lookup for Italian Government’s mail exchangers post I got intrigued by the idea of checking how many of those Italian Government’s MX mail servers support STARTTLS.
STARTTLS “offers a way to upgrade a plain text connection to an encrypted (TLS or SSL) connection” (Wikipedia) and, when it’s implemented on the MX SMTP server, it allows a STARTTLS-aware user’s outbound mail server to encrypt the traffic toward the recipient’s server.
A couple of days ago CloudFlare announced its public alpha release of their DNSSEC implementation. Since they are using the “recent” Elliptic Curve ECDSA P-256 (RFC6605) I wondered how many resolvers can have problems with signatures validation so I wanted to take a peek at the current situation as seen by the RIPE Atlas probes network.
Services and programs which used dnsbl.ahbl.org, ircbl.ahbl.org and rhsbl.ahbl.org need to be updated in order to avoid false positives:
X-Spam-Status: No, score=0.789 tagged_above=-999 required=6 tests=[BAYES_00=-1.9, DNS_FROM_AHBL_RHSBL=2.699, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Spamassassin configuration, for example, needs to be fixed:
# cat /usr/share/spamassassin/20_dnsbl_tests.cf | grep AHBL header DNS_FROM_AHBL_RHSBL eval:check_rbl_envfrom('ahbl', 'rhsbl.ahbl.org.') describe DNS_FROM_AHBL_RHSBL Envelope sender listed in dnsbl.ahbl.org tflags DNS_FROM_AHBL_RHSBL net reuse DNS_FROM_AHBL_RHSBL
Comment that block or (at least) force a score zero for the rule in your local configuration:
# cat /etc/spamassassin/local.cf | grep AHBL score DNS_FROM_AHBL_RHSBL 0