Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Who’s Talking to Your Browser?

David Evans
December 07, 2016

Who’s Talking to Your Browser?

Cybersecurity Awareness at UVA
Commonwealth Room
Charlottesville, VA
7 December 2016

David Evans

December 07, 2016
Tweet

More Decks by David Evans

Other Decks in Education

Transcript

  1. Who’s talking to your browser? David Evans Professor of Computer

    Science University of Virginia [email protected] https://www.cs.virginia.edu/evans Cybersecurity Awareness 7 December 2016
  2. 1

  3. 2

  4. 3

  5. Secure Web Connections 6 Client (Browser) MightBeEvil.org Server Image: https://unsplash.com/@brenomachado

    How can we know: (1)We are talking to the intended server (2)No one in the middle can observe or alter the content
  6. Encryption 7 Encrypt Decrypt Plaintext Ciphertext Plaintext Insecure Channel Key

    Key Symmetric Crypto: channel encrypted with shared secret key. Bob MightBeEvil.org Alice Client (Browser) Server
  7. Symmetric Encryption 8 Jefferson’s Cipher Wheel (1802) “on the periphery

    of each, and between the black lines, put all the letters of the alphabet, not in their established order, but jumbled, & without order, so that no two shall be alike.”
  8. Modern Symmetric Encryption 9 AES Round 128 or more key

    bits ~1017 J needed for most efficient possible brute force attack Very inexpensive: instructions built in to most processors
  9. Modern Symmetric Encryption 10 AES Round 128 or more key

    bits ~1017 J needed for most efficient possible brute force attack Very inexpensive: instructions built in to most processors
  10. Secure Web Connections 11 Client (Browser) MightBeEvil.org Server Image: https://unsplash.com/@brenomachado

    How can we know: (1)We are talking to the intended server ü No one in the middle can observe or alter the content
  11. Asymmetric (Public Key) Encryption: Confidentiality 12 Encrypt Decrypt Plaintext Ciphertext

    Plaintext Bob’s Public Key Bob’s Private Key Alice Bob Insecure Channel Asymmetric Crypto: Alice obtains Bob’s Public Key, and can send private messages to Bob.
  12. 13 Client Server Hello I’m “mightbeevil.org” and my public key

    is Generate random () Decrypt using Secure channel using Super-Simplified TLS Protocol Generates key pair: ,
  13. 14 Encrypt Decrypt Plaintext Ciphertext Plaintext Bob’s Public Key Bob’s

    Private Key Alice Bob Insecure Channel Signatures: Bob’s signs a message with his Private Key; Alice verifies signature with Bob’s Public Key. Asymmetric (Public Key) Encryption: Confidentiality Signatures
  14. 15 Client Server Hello Sign (“mightbeevil.org” has public key )

    Generate random () Decrypt using Secure channel using Super-Simplified TLS Protocol Generates key pair: , Verify Certificate using
  15. 17 static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t

    *signature, UInt16 signatureLen) { … if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; err = sslRawVerify(ctx, ctx->peerPubKey, dataToSign, dataToSignLen, signature, signatureLen); if(err) { sslErrorLog("SSLDecodeSignedServerKeyExchange: sslRawVerify returned %d\n", (int)err); goto fail; } fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; } Apple’s Implementation (cleaned up and excerpted)
  16. 18 Client Server Hello Sign (“mightbeevil.org” has public key )

    Generate random () Decrypt using Secure channel using Super-Simplified TLS Protocol Generates key pair: , Verify Certificate using How does the server get its certificate?
  17. 20

  18. 21

  19. 22

  20. 23

  21. 24

  22. 25 Client Server Hello Sign (“mightbeevil.org”has public key is )

    Generate random () Decrypt using Secure channel using Super-Simplified TLS Protocol Generates key pair: , Verify Certificate using How does the client (browser) get ?
  23. 26

  24. 27 Client Server Hello Sign (“mightbeevil.org”has public key is )

    Generate random () Decrypt using Secure channel using Super-Simplified TLS Protocol Generates key pair: , Verify Certificate using
  25. 28 Client Server Hello, Ciphers: [..., RSA-1024, DHE, …] Sign

    (“mightbeevil.org”has public key is ), Cipher: RSA-1024 Generate random () Decrypt using Secure channel using Slightly Less-Simplified TLS Protocol Generates key pair: , Verify Certificate using Picks ciphers to use
  26. 29 Client Server Hello, Ciphers: [..., RSA-1024, …] Sign (“mightbeevil.org”has

    public key is ), Cipher: DH-E Generate random () Decrypt using Secure channel using Slightly Less-Simplified TLS Protocol Generates key pair: , Verify Certificate using Picks ciphers to use
  27. Why Weak Ciphers are Supported? 30 Client Hello, Ciphers: [...,

    RSA-1024, …] Sign (“mightbeevil.org”has public key is ), Cipher: DHE-E Hello, Ciphers: [DHE-E, …]
  28. 31

  29. 32

  30. 35

  31. 40

  32. 42 • Internet explorer connects to a web server on

    port 443 using SSL. The data is encrypted. • Komodia’s SSL hijacker intercepts the communication and redirects it to Komodia’s Redirector. The channel between the SSL hijacker and the Redirector is encrypted. • At this stage, Komodia’s Redirector can shape the traffic, block it, or redirect it to another website. • Communication between the Redirector and the website is encrypted using SSL. • All data received from the website can be again modified and/or blocked. When data manipulation is done, it is forwarded again to Internet explorer. • The browser displays the SSL lock, and the session will not display any “Certificate warnings”. http://www.komodia.com/products/komodias-ssl-decoderdigestor (in archive.org)