Security Now 195

From The Official TWiT Wiki
Jump to: navigation, search
Security Now
Episode 195

Security Now 195: SSL

Steve describes the Internet's most-used security protocol, SSL, now evolved into TLS.

News & Errata

09:30 - 17:02

  • Steve has ordered a new Kindle DX
  • It has a larger screen
  • It has a higher pixel resolution
  • It has native PDF support
  • It will be better for books with diagrams
  • They will be shipped Summer 2009

17:03 - 20:50

  • Adobe has a zero day flaw
  • Links to discussion of this exploit
    • Secuina's Blog - This is interesting because they say that they can use the exploit without Javascript. Still, disabling Javascript closes one of the holes and who knows what future holes.
    • US CERT
  • No update is available as of today (May 7th 2009)
  • An update should be out in a week
  • For security reasons Steve recommends doing the following:
    • Open a PDF
    • Go to "Edit" in the upper left
    • Choose "Prefrences"
    • Select "Javascript" on the left
    • Uncheck "Enable Javascript"

Spinrite Story

20:51 - 21:50 (Doug Davis)

  • A listener had a laptop that would shut down when he tried to virus scan his PC. He thought it was a virus but couldn't find anything. He brought Spinrite on a hunch and ran it on the disk. It fixed the problem.

SSL

27:18 - 01:19:44

27:18 - 31:29

  • SSL came before TLS
  • TLS has formally replaced SSL
  • TLS is more bullet proof
  • Routers have permission to drop packets if they are overloaded
  • SSL is used to secure reliable protocols such as TCP
  • With TCP if packets are lost in transit TCP takes responsibility for resending them
  • Once they reach the recipient TCP reassembles them.
  • All contemporary web servers support the latest version, which is TLS 1.2. Firefox 2 and 3, IE7, and the latest versions of Opera, all the current browsers support TLS, as do servers.

31:30 - 43:00

  • IP protocol runs on top of ethernet protocol
  • This hosts TCP which provides IP addresses and port numbers
  • Then you run your applications on top of this
  • TLS inserts itself between the TCP layer and the application layer
  • SSL V1.0 was so broken it was never released
  • SSL V2.0 was the first version anyone ever saw
  • No traffic from the application layer is sent until the SSL connection is established
  • TLS provides authentication and tamper proofing
  • SSL V2.0 produced MD5 and SHA1 hashes and XORed the result

43:01 - 48:25

  • TLS 1.0 was SSL 3.0
  • We are now at TLS 1.2 (May 7th 2009)
  • TLS 1.2 removes SHA1 and MD5 and uses SHA 256
  • SSL 2.0 had a problem in that it used the same key for message authentication and encryption
  • SSL 3.0 used separate keys for authentication and encryption
  • A theoretical attack against SSL 2.0 was that:
    • A man in the middle could trick the server into believing that the client was much virtually incapable of any useful security and really interfere with the resultant strength of the connection.
  • One of the other things that was fixed in 3.0 was that that initial handshake was strengthened to prevent any kind of modification and man-in-the-middle attack.

48:25 - 58:32

  • There is now a finish message at the end of an exchange which involves the hash of everything that has been sent
  • Each end does this and checks there hashes match to verify there has been no modification in transit
  • If the hashes don't match the connection shuts down and they begin renegotiating
  • In SSL 3.0 there's a formal end of message communication
  • Virtual hosting, hosts multiple sites at a single IP
  • This causes a problem with SSL certificates because you can only bind a single certificate to a single IP

58:33 - 01:02:37

  • TLS has a more robust and stronger pseduorandom number generator based on HMAC

01:02:38 - 01:19:44

  • If you are going to use a secure connection you connect to port 443
  • The first data the sever receiving expects is the "Client Hello Message"

This contains:

  • The highest TLS or SSL protocol version it knows about
  • A 32 byte random number
  • A session ID
  • All compression methods it knows about
  • All cipher suites it knows about
  • The end points can cache the result of public key cryptography work
  • The server receives the "Client Hello Message" and:
  • Chooses the highest protocol level they can both use
  • Chooses the a cipher suite to use
  • Produces its own 32 byte random number
  • Checks it cache to see if it has that session ID in it

The server can then either:

  • Return a null session ID saying no resumption is agreed to
  • Return a new session ID, which is its way of saying, sorry, I don't have that in my cache, so this is the session ID we're going to use instead
  • Return the same session ID that the client sent, which is the server's formal acknowledgement that they're going to have an abbreviated handshake because it still knows and is in agreement with the client about the stuff they had before.

Then:

  • It sends its certificate message which has its public key bound to it

The client then receives these messages and:

  • If the session ID comes back that it offered, meaning that the server has retained the prior credentials, then at that point they need to do no more negotiation. The client is able to send what's called a Change Cipher Spec message, which essentially says, okay, this is the last thing I'm going to send you that is not under the cipher data that we have agreed to everything else from me henceforth will be.
  • The server, upon receiving it, echoes the same thing back. It sends the Change Cipher Spec message back to the client saying, okay, now we go under encryption.
  • They then exchange finish messages
  • The finish messages contain a hash of everything they have sent and received

Notable Quotes

Leo: Wow. You came to an end. I thought that was all one long sentence. I heard a period. That is the most complicated thing ever. But it works.

Sponsors

Audible

Audibledotcom.png
Dune by Frank Herbert (Abridged / Unabridged)
Narrated by Scott Brick, Orlagh Cassidy, Euan Morton, Simon Vance
  • Ad Time: 0:53-1:02 and 22:49-27:10

GoToMyPC

  • GoToMyPc
  • Q209-3
  • Ad Time: 0:33-0:51 and 6:09-9:24

Production Information

  • Recorded Date: May 6, 2009
  • Release Date: May 7, 2009
  • Duration: 1:25:26
  • Log line:
  • Edited by: Tony
  • Notes:
Info.png This area is for use by TWiT staff only. Please do not add or edit any content within this section.