Deutsch | English
This blog does not contain official statements of CERT.at, only personal opinions of the individual contributors.
DROWN update
2016/04/11

As I wrote in our initial DROWN blogpost, we're scanning .at for mail- and web-servers which are still supporting SSLv2. We're notifying our constituency and we see a steady drop in the number of servers (as measured by IP-Addresses) that are vulnerable:

drown-status-in-dotat

So it is slowly getting better.

Looking at the feedback we receive there is one point though that needs extra attention: Disabling all SSLv2 ciphers might not be enough. You need to disable the SSLv2 protocol.

See this FAQ from the DROWN website:

DROWN is made worse by two additional OpenSSL implementation vulnerabilities. CVE-2015-3197, which affected OpenSSL versions prior to 1.0.2f and 1.0.1r, allows a DROWN attacker to connect to the server with disabled SSLv2 ciphersuites, provided that support for SSLv2 itself is enabled. CVE-2016-0703, which affected OpenSSL versions prior to 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf, greatly reduces the time and cost of carrying out the DROWN attack.

We will thus continue to send warnings as long as SSLv2 is not completely disabled. For the typical Linux setup, this openssl.org post contains suitable configuration advise.

Author: Otmar Lendl

One quick note on DNSSEC Validation failures
2015/03/11

I wrote back in 2010 that ISPs should prepare for the inevitable backlash if their DNSSEC-aware resolvers black out an important domain.

We now had just such a case: the protagonists make it even juicier than I imagined: Comcast customers could not access the new HBO website where they could get the HBO programming without paying for a full cable TV package.

Accusation were flying, emergency debugging and cache clearing ensued and we're now in the "What went wrong?" and "./ style discussions" stage.

It looks like Comcast weathered that storm pretty well. This may be a result of good social media work, a quick fix from HBO, and the fact that Google's 8.8.8.8 nameserver also does DNSSEC validation.

Author: Otmar Lendl

Lesestoff: Ron Deibert
2014/11/26

Wir leben nicht nur in einer technisch interessanten Zeit, sondern auch die gesellschaftliche Diskussion rund um Geheimdienste, Privatsphäre, Verschlüsselung, 0-Days bis hin zu "Cyberwar" ist für die Zukunft des Internets sehr relevant.

Dazu wird viel geschrieben und publiziert, ich will hier auf einen aktuellen Artikel von Ron Deibert hinweisen, weil er auch die Rolle der CERTs in diesem Kontext anspricht:

There are international implications of the cyber security syndrome. Top-down, secretive approaches breed vicious cycles of mutual suspicion and hostility that stifle numerous forms of lower level cooperation. Consider the deleterious impact on the information sharing practices of national-level computer emergency response teams (CERTs). In an ideal world, CERTS are entirely apolitical and operate as early-warning systems that share network threat information with each other seamlessly. But as Asia Pacific CERT coordinator Yuri Ito explained at the 2013 Bali IGF, the growing influences of national security agencies and the rivalries and suspicion they engender have eaten into the system of international trust and cooperation. If CERTs are seen as "instruments of state competition," says Ito, "it can become very hard to share information." Jeopardizing the integrity of CERTs in this way -- the frontline sensors for computer security threats worldwide -- is a clear indication that we are down the wrong path.

Ich kann nur empfehlen, den ganzen Text zu lesen.

Author: Otmar Lendl

Completed: Maintenance work on Tuesday, Sep. 30th, 2014
2014/09/29

Because of required changes in our firewall infrastructure, all Internet-reachable services of CERT.at will be unavailable for some time on Tuesday, September 30th, 2014, starting at about 9am CEST. An "emergency" website with restricted functionality will be made available.

In urgent cases please contact us by telephone: +43 1 505 64 16 78.

We will update this post once the work is completed.

Update: work was completed at around 10am; overall outage was about 15 minutes.

Author: Robert Waldner

<< Previous Next >>
Last Change: 2018/8/1 - 17:21:34
Haftungsausschluss / Data Protection & Privacy Policy