Show 65 – Second Shot of Strong Opinion

This show in all about Beast Attack on SSL, Cisco Nexus network designs and limitations of the FEX switching, and a bitch slap between MrsY and Greg on DNS Load Balancers.

This is the second half of the show recorded on the 25th Sep, 2011. You can find the first show.

Beast Attack on SSL.

MrsY says:

Felt so depressed after reading about the new SSL vuln, that I didn’t even want to go to work the next day. I can’t figure out what we’re doing anymore. Why aren’t we deploying TLS 1.1 and 1.2?! Everyone knew this was coming. “…Short for Browser Exploit Against SSL/TLS, BEAST performs what’s known as a chosen plaintext-recovery attack against AES encryption in earlier versions of SSL and its successor TLS, or transport layer security. The technique exploits an encryption mode known as cipher block chaining, in which data from a previously encrypted block of data is used to encode the next block.”

Pretty good post on mitigating the threat and what it means

Saw some figures from Ivan Ristic’s site regarding the prevalence of older (vulnerable) versions of SSL and TLS:

And from the God of Crypto (i.e. Blowfish), Bruce Schneier:

“The tool is based on a blockwise-adaptive chosen-plaintext attack, a man-in-the-middle approach that injects segments of plain text sent by the target’s browser into the encrypted request stream to determine the shared key. The code can be injected into the user’s browser through JavaScript associated with a malicious advertisement distributed through a Web ad service or an IFRAME in a linkjacked site, ad, or other scripted elements on a webpage. Using the known text blocks, BEAST can then use information collected to decrypt the target’s AES-encrypted requests, including encrypted cookies, and then hijack the no-longer secure connection. That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long.

The attack, according to Duong, is capable of intercepting sessions with PayPal and other services that still use TLS 1.0­which would be most secure sites, since follow-on versions of TLS aren’t yet supported in most browsers or Web server implementations.”

Adaptive chosen-plaintext attack, where the cryptanalyst makes a series of interactive queries, choosing subsequent plaintexts based on the information from the previous encryptions.

“The chosen plaintext-recovery at the heart of BEAST attacks algorithms that use a mode known as CBC, or cipher block chaining, in which information from a previously encrypted block of data is used (as an IV) to encode the next block. CBC is present in both AES and DES, but not in RC4.”

And finally, best analysis of how BEAST works by the Tor developers.

Cisco Nexus Switch Designs

Ethan says

I met with Cisco this week to design a small Nexus core/agg/access. We could talk through why they guided me the way they did. AKA, why is the 7K lagging behind the 5K in features? Shouldn’t the 5K be the leader? Or is it all about the non-blocking? How come FEXen can’t dual-home to a pair of 7Ks? And does it matter? Etc.

Using DNS Load Balancers or BIND to manage DNS domains

MrsY and Greg go head to head on whether BIND is better than using DNS Load Balancer appliances for managing DNS domains. Talked about F5 GTM, NetScaler Global DNS, Cisco GSLB or using a managed DNS service.

Greg Ferro
Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count. He is a host on the Packet Pushers Podcast, blogger at and on Twitter @etherealmind and Google Plus.
Greg Ferro
Greg Ferro
  • Markku Leiniö

    Great show, once again! Two comments though.

    1. Active-active FEXes are really active-active, meaning that the both Nexus 5000s upstream are forwarding for the active-active FEXes. Think about the normal port-channel load balancing: FEX calculates the hash based on src-dst-IP-src-dst-port (or as configured on N5k) and selects one port channel link from the uplink bundle to send the frame to.

    2. The cost of 10G transceivers: You can seriously lower the expenses in 10G transceivers (and still use Cisco gear) by deploying the FEXes with FET transceivers. They are only available in bundles with FEXes however. The calculated list price for a FET is something like 1/6 or 1/8 of a 10G-SFP-SR. SR = 300 meters with OM3, FET = 100 meters with OM3. 100 meters is plenty for usual FEX implementations.

  • Martin

    Cisco SE showed told us that dual-homing of FEXs to 7Ks isn’t on the current roadmap (through to end 2012) and doesn’t seem likely any time soon for ‘technical reasons’.

  • Doron Livny

    Would it make more sense to use NX7K at the core, and NX3K as TORs, instead of 7K (core) 5K (agg) 2K (TOR)?