SSL, CAs and keeping your stuff safe

Transcript

1. 1.

   SSL, CAs and keeping your stuff safe B
   QSFTFOUBUJPO
   CZ
   BSNJO
   SPOBDIFS
   GPS
   QZHSVOO
    http://lucumr.pocoo.org/ —

   @mitsuhiko
2. 2.

   SSL, CAs and keeping your stuff safe B
   QSFTFOUBUJPO
   CZ
   BSNJO
   SPOBDIFS
   GPS
   QZHSVOO
    http://lucumr.pocoo.org/ —

   @mitsuhiko a capitalistic and system conformant talk about encryption
3. 3.

   Armin Ronacher Independent Contractor for Splash Damage / Fireteam Doing

   Online Infrastructure for Computer Games
4. 4.

   … The Problem with Programmers ~ Epilogue ~

5. 5.

   Programmers think everything is a technical problem

6. 6.

   Fraud ~ Chapter 1 ~

7. 7.

   XXXX-XXXX-XXXX-1234 What is the worst that can happen?

8. 8.

   What makes Credit Card Numbers “secure”?

9. 9.

   theft ere will always be criminals

10. 10.

    prevented But what damage can they do?

11. 11.

    Bitcoin A Credit Card Strong Encryption Potentially No Encryption 256

    bit private key 16 digit number + checksum decentralized centralized √ x
12. 12.

    But I'd rather lose my credit card …

13. 13.

    Never

14. 14.

    LOL

15. 15.

    We Accept Stolen Creditcards

16. 16.

    e Protocol e Process is insecure is secure

17. 17.

    If the aud percentage is smaller than the transaction fees

    we're all good.
18. 18.

    It's too easy to forget the bigger picture

19. 19.

    of Lock Symbols and Encryption ~ Chapter 2 ~

20. 20.

    the lock symbol is a lie

21. 21.

    the lock stands for secure

22. 22.

    but so is encryption 8 7

23. 23.

    such security

24. 24.

    such buzzwords CRIME BEAST Heartbleed BREACH PFS

25. 25.

    users need to understand how to keep good om bad

    lock symbols / good om bad encryption. = -
26. 26.

    but even developers are not sure yet …

27. 27.

    remember why you encrypt (NSA

28. 28.

    Why do we Encrypt Traffic? ~ Chapter 3 ~

29. 29.

    None
30. 30.

    public WiFi the unencrypted browser session kilLed

31. 31.

    ? Who is the Attacker?

32. 32.

    om secret agents to idiots

33. 33.

    om targeted to untargeted

34. 34.

    om low to high probability

35. 35.

    What You Need for Encryption ~ Chapter 4 ~

36. 36.

    passive vs active eavesdropping encryption authentication

37. 37.

    $ ssh pocoo.org The authenticity of host 'pocoo.org (148.251.50.164)' can't

    be established. RSA key fingerprint is 14:23:83:02:45:f9:9c:d0:eb:39:c7:14:42:f5:9f:9c. Are you sure you want to continue connecting (yes/no)?
38. 38.

    your user does not check ngerprints (your

39. 39.

    e Certificate Authorities thus:

40. 40.

    CAs are worthless for securing APIs let it be known

    that
41. 41.

    Protecting APIs and Services ~ Chapter 5 ~ (non

42. 42.

    The Only Rule to Follow

43. 43.

    run your own CA issue certi cates for 24 hours

    trust your own CA only screw re ocations
44. 44.

    You trust your own CA by distributing the certi cate

    to everybody.
45. 45.

    If your root gets compromised, distribute new root certi cates.

46. 46.

    If an individual key gets compromised, in less than 24

    hours everything is ne.
47. 47.

    from requests import get resp = get('https://api.yourserver.com/', verify='your/certificate.bundle')

48. 48.

    “But my awesome AntiVirus says your certi cate is not

    trusted.” — Windows User
49. 49.

    Certificate Authorities Again ~ Chapter 6 ~

50. 50.

    Hardly news: CAs are Broken

51. 51.

    But why are the broken?

52. 52.

    I Trust “TÜRKTRUST Elektronik Serti ka Hizmet Sağlayıcısı” to ouch

    for the identity of any domain on the planet. Trusting a CA:
53. 53.

    trusting half the world: one shitty employee in one shitty

    CA is enough to break your security.
54. 54.

    I Trust “Comodo” to ouch for the identity of “Foo

    Owner” foo.com. I only trust “Foo Owner” to ouch for the identity of api.foo.com What we actually want:
55. 55.

    if you have seen google.com being from Verisign and all

    the sudden google.com becomes a StartSSL certificate you know something might be wrong.
56. 56.

    Soon: Certificate Pinning?

57. 57.

    Frack OpenSSL and Question “Best Practices” ~ Chapter 7 ~

58. 58.

    Self-Signed Certificates are not bad. Just in browsers.

59. 59.

    Never. Ever. Look at OpenSSL's Source.

60. 60.

    OpenSSL's "patches" are even worse: Apple's OpenSSL always trusts system

    store :-/
61. 61.

    Requests by default trusts it's own bundle :-/ (And does

    not even properly document how to use custom ones)
62. 62.

    With Heartbleed SSL was less secure than no SSL :-/

63. 63.

    Growing SSL ~ Chapter 8 ~

64. 64.

    Credit Cards were made for thousands of people Certificate Authorities

    were made for hundreds of sites
65. 65.

    OpenSSL was probably improperly audited

66. 66.

    See “OpenSSL Valhalla Rampage” :-( “i give up. reuse problem

    is unixable. dlg says puppet crashes” — tedu
67. 67.

    Plan for Failure ~ Chapter 9 ~

68. 68.

    what

69. 69.

    what happens to your user if he gets hacked? (food

    for thought: keyloggers are still a thing)
70. 70.

    what happens to your data

71. 71.

    what happens to your company

72. 72.

    encryption is hardened security it must not be your only

    defense
73. 73.

    ? Feel Free To Ask Questions Talk slides will be

    online on lucumr.pocoo.org/talks You can find me on Twitter: @mitsuhiko And gittip: gittip.com/mitsuhiko Or hire me: armin.ronacher@active-4.com