Tasty news bytes from networking land: Route security, Cisco cert death, ETSI and more

Roundup Cisco admins, you thought your week was over, right? Sorry: if you have kit that runs Adaptive Security Appliance software or the Firepower Extensible Operating System, there's one more item on the task list: updating your certificate.

Switchzilla's field notice explained that Cisco's root CA for tools.cisco.com was rolled over to a QuoVadis Root CA 2 cert on October 5, and that could affect “Smart Licensing and Smart Call Home functionality for all versions” of ASA or FXOS.

That causes a Communication message send response error error, and because the platforms can't register with the Cisco servers, “smart licenses might fail entitlement and reflect an Out of Compliance status”.

You can either upgrade, or import the new cert from the CLI.

And there's one more wrinkle to be aware of: the QuoVadis cert isn't FIPS-compliant. If you need FIPS compliance, there's a different certificate to import, the HydrantID SSL ICA G2 intermediate certificate, also available from the CLI.

Better route security comes to APNIC

The Asia-Pacific Network Information Centre, APNIC, this week announced extra routing security.

Its members can now run Resource Public Key Infrastructure (RPKI) operations in MyAPNIC, including generating an AS0 Route Origin Authorisation.

As we explained in September, RPKI means a network can positively identify its authority to make route announcements, and America's National Institute of Standards and Technology recommended its adoption.

ETSI publishes TLS 1.3 “middlebox” workaround

The European Telecommunications Standards Institute, ETSI, this week published what it called a “Middlebox Security Profile specification”, Enterprise TLS (eTLS).

Hang on, I hear you ask: isn't the Internet Engineering Task Force responsible for TLS standards?

Yes, and that was part of the problem. Welcomed for improving user security, TLS 1.3 is unloved by attackers, spooks, and those who want to proxy the security protocol at the enterprise edge.

IETF standards bods have considered the matter of TLS 1.3 proxies, but so far nobody's hummed up sufficient support to get an RFC published – and that's where ETSI comes in. It pitches eTLS as an enabling technology that allows net admins to carry out operations like “compliance, troubleshooting, detection of attacks (such as malware activity, data exfiltration, DDoS incidents), and more, on encrypted networks”.

eTLS only allows decryption where “both parties in a connection … are under the control of the same entity”, in which case it implements its own key exchange mechanism so TLS 1.3 packets can be sniffed snooped decrypted.

When that happens, users can see that their communications are being examined by checking the certificate (which everybody knows how to do, right?).

As we've reported more than once, middleboxes aren't just invasive, they're frequently insecure.

But at least there's a standard for them now …

BIND, OpenSSH replace Wordpress and Drupal in ZDI bounty-list

The Zero Day Initiative has tweaked its Targeted Incentive Program, replacing Drupal and Wordpress with OpenSSH and BIND as “high value” targets.

A successful OpenSSH code execution chain will earn you a cool $200,000, which ZDI said reflects “how much we rely on OpenSSH”.

BIND, the world's most common DNS server, is also down for $200k, as is Windows SMB, for versions newer than 1.0.

IETF docs get sloshed

A four-party collaboration has come up with an Internet-Draft answering a conundrum you might not know existed: what's a good way to render long lines in Internet standards documents?

Recall that the Internet standards process is ancient, and as a result, it has inherited a 72-character line length from ”green-screen” terminals.

A few years ago, the IETF adopted XML as the canonical standard for storing documents like drafts and RFCs, but humans still need to read plain text.

Code fragments pose a problem (as does the ubiquitous ASCII art of Internet documents), because they need to be stored and rendered as they are, if possible.

“Handling Long Lines in Artwork in Internet-Drafts and RFCs” suggests a simple approach: use a backslash (“\”, also referred to as a “slosh”) to indicate that a line has been folded.

As Kent Watsen (Juniper), Qin Wu (Huawei), Adrian Farrel (Old Dog Consulting) and Benoit Claise (Cisco) wrote: “The approach produces consistent results regardless of the content and uses a per-artwork header. The strategy is both self-documenting and enables automated reconstitution of the original artwork.” ®