Christopher Armstrong

Transcription

SO THE NEXT SPEAKER IS ASHWINI ORUGANTI, AND THE TITLE OF HER TALK IS INTRODUCTION TO HTTPS: A COMEDY OF ERRORS. SO PLEASE WELCOME HER. >> HI, EVERYONE. I'M ASHWINI. I WRITE A LOT OF CODE OF -- WHAT'S THAT? OKAY. YEAH, [INAUDIBLE] IN THE PAST, AND HIPPY VM, WHICH IS A PHP VIRTUAL MACHINE WRITTEN BY PYTHON. AND I'VE ALSO SPENT SOME TIME IN [INAUDIBLE] TRYING TO READ A TLS 1.2 IMPLEMENTATION AND PYTHON. TODAY I'M GOING TO TALK ABOUT HTTPS. SO LET'S START WITH SOME CODE. IT'S A SIMPLE LINE THAT TRIES TO OPEN A WEBSITE, GIVE IT SOME DATA, IN THIS CASE, SECRET -- A SECRET AS A TOKEN. AND THERE'S HTTPS IN THE URL, SO IT LOOKS SECURE, RIGHT? I MEAN, HTTPS STANDS FOR HTTP SECURE. YOU WOULD THAT I IT. AS BAD AS NOT USING ANY ENCRYPTION AT ALL. SPOOFS ON THE NETWORK CAN STEAL THE SECRET SADLY, THIS IS PRETTY MUCH INSECURE, AND IT'S WITH NOT MUCH WORK. THE PROBLEM HERE IS THAT YOUR [INAUDIBLE] DOES NOT VALIDATE OR CERTIFICATE IT AT ALL. PYTHON 2.7.9, WHICH WAS RELEASED A FEW MONTHS AGO SUPPORTS TLS VALIDATION BUT EVEN THEN IT'S NOT ALL BY DEFAULT. AND THERE WAS NO SUPPORT FOR IT AT ALL BEFORE THAT. BEFORE MOVING ON, LET'S TALK A BIT ABOUT THE TYPES OF ATTACKS THAT CAN HAPPEN ON ANY KIND OF COMMUNICATION. THERE A'S PASSIVE ATTACKS WHERE THE ATTACKER ONLY NEEDS TO BE ABLE TO LISTEN TO THE COMMUNICATION WITHOUT INJECTING A [INAUDIBLE]. FOR EXAMPLE, A CRYPTO FLAW MIGHT ALLOW AN ATTACKER TO READ YOUR DOC. ACTIVE ATTACKS ALLOWS SENDING DATA TO EITHER PARTY OR TRAFFIC. THIS USUALLY TAKES THE FORM OF A MAN IN THE MIDDLE ATTACK. TLS IS LARGELY NOT VULNERABLE TO PASSIVE BEFORE LEARNING HOW THE SECURITY HOLE I SHOWED YOU CAN BE FIXED, LET'S LEARN A LITTLE ATTACKS BUT THERE IS ALWAYS THE POSSIBILITY. ABOUT TLS. MOST OF THE -- I KNOW THIS IS MISLEADING BECAUSE THE TOPIC SAYS HTTPS. MOST OF THE ATTACK IS ABOUT TLS BECAUSE HTTPS IS MOSTLY HTTPS ON TLS. BEFORE WE MOVE ON. SSL IS SECURITY SOCKETS. SSL IS OLD AND BUSTED AND SHOULDN'T BE USED ANYMORE. I MEAN, THE MOST RECENT LATEST RELEASE OF SSL, SSL 2.0 WAS IN 1996. AND TLS 1.0 WAS FIRST RELEASED IN 1999. AND TLS 1.2, WHICH WAS THE MOST RECENT ONE NOW, WAS RELEASED IN 20082008. SO TLS HAS SUPERSEDED SSL. DON'T USE SSL. PLEASE USE TLS. NOW, TLS WAS DESIGNED TO SECURE TCP CONNECTIONS. THERE ARE TWO ASPECTS OF ACTUALLY DOING THE SECURING. CERTIFICATE CAN BE USED FOR AUTHENTICATION. LIKE CERTIFICATES ALLOW US TO IDENTIFY A PEER THE ENCRYPTION IS PRETTY MUCH USELESS. IT'S LIKE PICKING UP A PHONE AND ACTUALLY WITHOUT AUTHENTICATION. VERIFYING WHO YOU'RE TALKING TO BEFORE YOU GIVE THEM YOUR CREDIT CARD NUMBERS. I MEAN, DON'T DO THAT. THAT'S LIKE BAD. BUT STILL. SO A VALIDATION ANSWERS QUESTIONS LIKE CAN I TRUST THIS WEBSITE. SPECIFICALLY, IS THIS WEBSITE BEING SERVED BY THE SAME PERSON WHO OWNS THE CERTIFICATE FOR THE WEBSITE. THIS IS A FORM OF AUTHENTICATION BECAUSE IT'S A VERIFICATION OF IDENTITY. SO HOW DOES VALIDATION REALLY WORK? THE VALIDATE CERTIFICATES BY USING PUBLIC INFRASTRUCTURE. SO WEBSITES HAVE CERTIFICATES WHICH ARE AUTHORIZED BY ORGANIZATIONS CALLED CERTIFICATE AUTHORITIES, RCAS. THE CA AUTHORIZES CERTIFICATES WITH CRYPTOGRAPHIC NATURES. YOUR COMPUTER HAS A BIG LIST OF CAS THAT IT TRUSTS. IT GOES TO ITS DATABASE OF CAS CHECKING IF IT IS SIGNED BY ANY. SO WHENEVER A CLIENT RECEIVES A CERTIFICATE, AFTER THAT, IT CAN DECIDE IF IT TRUSTS THE WEBSITE OR NOT. OR NOT. SO THERE WOULD STILL BE SOMETHING MISSING. IMAGINE BOB'S IT PERSON GETS A CERTIFICATE FOR BOB'S BURGERS.COM. IT IS SIGNED BY A TRUSTED CA, SO IT'S TOTALLY LEGITIMATE. SO BUT THE IT PERSON GOES TO STARBUCKS AND SETS UP A SPOOF SERVER THAT READ TLS TO.COM TO THEIR LAPTOP. SO THEY USED THE BOB'S BERGERES FOR THE WEBSITE, RIGHT? SO THE CLIENT WOULD SAY THAT LOOKS GOOD BECAUSE IT'S SIGNED BY MY CA BUNDLE. BUT THAT'S LIKE WRONG. SO FORTUNATELY WE HAVE HOSTING CHECKING TO THE RESCUE. CLIENTS CAN CHECK THAT THE HOST NAME ON THE CERTIFICATE THEY RECEIVED IS THE SAME THAT THEY REQUESTED. NOW, THIS IS AN IMPORTANT LINE OF DEFENSE THERE ARE OTHER THINGS, OF COURSE, THAT WE MUST CHECK WHEN VALIDATING A TLS CERTIFICATE AGAINST MIT ATTACKS. PROPERLY. FOR EXAMPLE, IS THE CERTIFICATE PAST ITS EXPIRATION DATE. AND IF THE CERTIFICATE WAS COMPROMISED, IT CAN ALSO BE REVOKED. REVOCATION IS A WHOLE DIFFERENT DOC, IT'S A WHOLE DIFFERENT MESS, AND I WON'T SPEAK OF IT NOW. BUT JUST SAYING IT'S THERE. SO THAT WAS AUTHENTICATION AND CERTIFICATE VALIDATION. NEXT COMES THE ACTUAL ENCRYPTION. SO FOR THE PURPOSE OF THIS TALK I'M GOING TO LET IT BE A BLACK BOX, AND FOR MOST NORMAL USAGE IN OUR DAY-TO-DAY LIVES WE DON'T NEED TO KNOW WHAT THE MAGICAL THING THAT ENCRYPTION IS. SO I'M JUST GOING TO MOVE ON AND NOT LIKE [INAUDIBLE] ABOUT THIS. INSTEAD I'M GOING TO TALK ABOUT TLS MORE. SO HOW DOES IT WORK? LET'S TRY AND WALK THROUGH A TLS SESSION TLS IS A PROTOCOL. SO THERE'S A SERVER AND A CLIENT INVOLVED. NEGOTIATION TO SEE THIS. THE FIRST AND THE MOST IMPORTANT THING ABOUT TLS IS THE HANDSHAKE. SO THE CLIENT TRIES TO ESTABLISH A CONNECTION BY SENDING A CLIENT HELLO MESSAGE. AND WHILE A LOT OF STUFF FOLLOWS, THIS IS KIND OF A HIGH LEVEL LOOK AT IT. THE SERVER RESPONDS WITH A SERVER HELLO. THEY EXCHANGE INFORMATION, KEYS AND OTHER THINGS NEEDED TO ESTABLISH A SECURE CONNECTION. AND THEN LIKE A LOT OF [INAUDIBLE] ARE MADE. THEY NEED TO AGREE ON A PROTOCOL VERSION, HOW TO GUARD THEM. CYBER SUITE. BUT ONCE ALL THESE DECISIONS ARE MADE, IT'S A MAGICAL MATH, AND A COUPLE OF TLS MESSAGES, THE SUITE OF ENCRYPTION IS FLIPPED, AND, YEA, EVERYTHING IS SECURE. NEXT, I WANT TO TALK ABOUT TWO VERY BROAD CLASSES OF SOFTWARE. FIRST LET'S LOOK AT THE ONES THAT HOW TLS IS IMPLEMENTED. I'M JUST GOING TO THROW SOME TLS IMPLEMENTATIONS AT YOU. SO SOFTWARE THAT IMPLEMENTS TLS. I'M NOT GOING TO DISCUSS EACH ONE OF THEM SPECIFICALLY. BUT, YEA. OPEN SSL, VERY POPULAR. [INAUDIBLE] SSL, A DISCLAIMER HERE, I DON'T THINK [INAUDIBLE] SSL HAS A GUARANTEED OR STABLE INTERFACE SO IT'S NOT FOR ANYONE BUT GOOGLE YET. THERE'S SECURE TRANSPORT, APPLE STING. THERE'S NEW TLS FOR LINUX HIPPIES. SO ALL THESE IMPLEMENTATIONS HAVE A LOT OF FLAWS. BOTH IN THE WAY THAT THEY'RE IMPLEMENTED AND IN THE APIS THAT THEY EXPOSE APIS THAT THEY EXPOSE. THERE IS A COMMONALITY IN ALL THE IMPLEMENTATIONS OF TLS. THEY ARE ALL IN EITHER C OR C++. THEY HAVE ALL HAD BUCKS BUGS CAUSED BY MEMORY AND SAFETY OF THE. SOME OF THEM ARE REALLY BIG. HEART BLEED ALLOWED ATTACKERS TO STEAL AND IT WAS NOT A CRYPTO FLAW. IT WAS JUST A CLASSIC CODE AND SEE MOMENT. RETREAT RANDOM DATA FROM THE RAM. A LOT OF FLAWS ARE JUST PLAIN LOGIC ERRORS, TOO. MULTIPLE TLS IMPLEMENTATIONS HAD A BUG ACCEPTING ANY CERTIFICATE AS VALID IF IT WAS SIGNED BY A TRUSTED NON-CA CERTIFICATE. I REPEAT, EVEN IF THE CERTIFICATE IS NOT A CERTIFICATE AUTHORITY CERTIFICATE, FOR EXAMPLE, THE BOB'S BURGERS EXAMPLE, THAT CERTIFICATE COULD SIGN THE WRONG CERTIFICATE FOR SMLA.COM AND IT WILL BE ACCEPTED. YOU PROBABLY WON'T BE ABLE TO READ THE CODE ON THE SLIDE. BUT IT IS THE OFFICIAL SSL EXAMPLE FOR MAKING CLIENT CONNECTIONS. I TOOK IT FROM THE OFFICIAL DOCUMENTATION, AND THIS IS -- THE EXAMPLE GO TO CONNECT TO A RANDOM WEBSITE ON 433 AND MAKE A HARD CODED [INAUDIBLE] REQUEST. AND THIS IS LIKE NOT USER FRIENDLY. IT'S NOT JUST A VERBOSE API, IT'S AN UNOPINIONATED API. THAT MEANS THAT YOU HAVE TWO [INAUDIBLE] REMEMBER THE DECISIONS I MENTIONED FROM THE TLS HANDSHAKE EARLIER. SETTINGS. FORCING APPLICATION DEVELOPERS TO MAKE SHE'S DECISIONS IS BAD. FIRST OF ALL, IT ALLOWS THEM TO MAKE BAD DECISIONS. AND THEN IT PREVENTS APPLICATIONS FROM BEING MIGRATED EASILY TO BETTER SETTINGS AND THEN THEY BECOME AVAILABLE. SO THIS COULD BE SO MUCH BETTER. NOW, THEY'RE NOT JUST IMPLEMENTATION FLAWS, SSL AND TLS HAVE A ROCKY HISTORY WITH BACKWARDS COMPATIBILITY. THERE HAVE BEEN A TON OF DOWNGRADE ATTACKS THAT ALLOW ATTACKERS TO PREVENT SECURE CONNECTIONS FROM BEING ESTABLISHED, WHICH FURTHER ALLOWS THEM TO TAKE ADVANTAGE OF THE LESS SECURE SESSIONS THAT THEY HAVE CAUSED. SO EVEN THOUGH HTTPS IS JUST HTTP ON TLS, THERE ARE A LOT OF INTERESTING, UNIQUE ATTACK [INAUDIBLE] HERE. THERE ARE NOT JUST PROBLEMS WITH THE AUTHENTICATION OR CRYPTOGRAPHY, RATHER THERE ARE ATTACKS BASED ON SUBTLE BROWSER BEHAVIOR. INTERESTING ONE. SO THE USER CONNECTS TO A SECURE HTTP WEBSITE SO, FOR EXAMPLE, COOKIE STEALING IS AN THAT STORES A COOKIE ON THEIR SYSTEM. SO IS FAR SO GOOD, RIGHT? THE ATTACKER CANNOT ATTACK THIS ENCRYPTED GRAPHIC WEBSITE. BUT THEY WAIT FOR YOU TO SUBMIT AN UNENCRYPTED HTTP REQUEST TO ANY OTHER WEBSITE. THEN THEY STEP IN AND RESPOND WITH A REDIRECTED DOMAIN BUT API. BECAUSE ANY SITE CAN ISSUE A REDIRECTION TO ANY OTHER SITE, YOUR BROWSER HAPPILY FOLLOWS, AND THIS RESULTS IN A PLAIN TEXT CONNECTION TO THE ATTACKER WEBSITE WHICH INCLUDES ALL THE NON-SECURE COOKIES IN YOUR BROWSER'S POSSESSION. THIS CAN BE MITIGATED BY SETTING A SECURE FLAG ON COOKIES. BUT MANY DEVELOPERS FORGET TO DO THAT. AND THIS EXEMPLIFIES HOW TRICKY SECURING HTTPS IS. IT'S AN EXTREMELY COMPLICATED COMBINATION OF FACTORS. THERE IS STILL COOKIE INJECTION. IT USES A SIMILAR TECHNIQUE, NON-ENCRYPTION AND EVEN THEN THE COOKIES ARE FLAGGED SECURE, IN THE MIDDLE CAN RETARGET THE DOMAIN ON AP, AND THEN SEND A SEND COOKIE HEADER TO OVERWRITE COOKIES FOR THAT WEBSITE. SO YOUR SECURE COOKIES AREN'T RESISTANT TO TAMPERING EITHER. IN A LOT OF CASES, THE USER CAN BE CONSIDERED A SECURITY FLAW BECAUSE THEY DO INSECURE THINGS, RIGHT? BUT, FOR EXAMPLE, CLICKING THROUGH CERTIFICATE WARNINGS. BUT I DON'T THINK IT'S REALLY THE USER'S FAULT. WE DON'T PREVENT THEM FROM CONNECTING TO WEBSITES WITH INVALID CERTIFICATES BECAUSE WE TRAIN THEM TO CLICK THROUGH WARNINGS BY HAVING SO MANY OF THEM. SO MOVING ON TO SOFTWARE THAT ACTUALLY USES TLS. LET'S LOOK AT THE EXAMPLE THAT WE HAD IN THE BEGINNING. NOW, EVEN THOUGH IT'S SUPPORTED TLS, IT WAS USED INCORRECTLY AND IS CAUSING HUGE SECURITY SO IT'S EASY TO BLAME URLLIB2 HERE, BUT I THINK IF THERE'S A FAILING OF INDUSTRY. HOLES. IF EASY OPINIONATED SECURE LESS APIS EXISTED WE WOULDN'T HAVE HAD THIS PROBLEM. THIS IS JUST LIKE THE USABILITY PROBLEM WITH BROWSERS BUT FOR DEVELOPERS INSTEAD. FORTUNATELY THERE'S THE REQUEST'S LIBRARY. [INAUDIBLE] SITE HAS A BAD CERTIFICATE, BUT IT IS SAD THAT URLLIB2, WHICH I THINK EVERY NEW [INAUDIBLE] GRAMMAR WOULD USE IS HORRIBLY INSECURE. EVERYONE IN THE NO USERS REQUESTS, BECAUSE IT'S SECURE. BUT ACTUALLY BECAUSE IT'S EASIER TO USE THAN URLLIB2, BUT IT'S UNSECURE. WELL, I'M SORRY THAT I'M BEING SO NEGATIVE ABOUT ALL THESE FLAWS AND ATTACKS, BUT IT'S TRUE, THINGS ARE GETTING BETTER. PEOPLE ARE BEGINNING TO CARE. OPEN SSL IS GETTING MORE ATTENTION. SO NEW ALTERNATIVES ARE SHOWING UP, WHICH MEANS THAT THERE'S HOPE. BUT THINGS COULD STILL BE BETTER. MOST OF THESE LIBRARIES ARE STILL [INAUDIBLE] THERE'S A PROBLEM BY CS CRYPTOGRAPHY WHICH IS A PROJECT THAT AIMS TO HAVE OPINIONATED APIS IN MEMORY AND SAFE LANGUAGES. WHILE STILL EXPOSING LOW LEVEL PRIMITIVES REQUIRED. SO THIS HIDES THE COMPLEXITY AND AT THE SAME TIME EXPOSES IT TO THE ONES WHO ACTUALLY WANT TO SEE IT. THERE'S TLS -- BY THE WAY, YOU CAN ACCESS THESE ON GET HUBS GOT COME/CRYPTOGRAPHY. THERE'S PYCA TLS WHICH IS AN EASY TO USE THAT I LOGGED ON FOR A WHILE DURING THE OPEN SOURCE RETREAT LAST YEAR. I HAVEN'T HAD THE TIME TO WORK ON IT FURTHER BUT IF ANY OF YOU OUT HERE ARE INTERESTED, PLEASE, PLEASE CONTRIBUTE, AND I'LL MAKE SURE THAT I MAKE [INAUDIBLE] THAT YOUR CONTRIBUTIONS DON'T GO TO WASTE. SO MY FAVORITE PART OF THE TALK. WHAT CAN WE DO? THERE'S A [INAUDIBLE] CALLED SSL TEST ON SSL LABS.COM. YOU CAN USE THAT. IT'S REALLY GOOD. SO HYNEK HAS A PAGE ON CLS. DEFINITELY CHECK IT OUT. YOU CAN ALSO TEST YOUR CLIENTS AGAINST IT'S FREQUENTLY UPDATED SO YOU SHOULD SERVERS WITH BAD CERTIFICATES TO MAKE SURE THAT EVERYTHING IS FINE. BUT SO HERE I WAS LOOKING FOR A KNOWLEDGE BASE OF SORTS, WHERE YOU COULD JUST HAVE A LIST OF ALL THE SERVERS WITH BAD CERTIFICATES AND ANYONE WHO WANTED TO TEST THEIR CLIENTS COULD CHECK AGAIN AGAINST IT. I DIDN'T FIND IT. AND I'VE BEEN TALKING TO IAN WHO WORKS ON REQUESTS AND MAINTAINS A LOT OF AWESOME LIBRARIES. BUT IF YOU'RE TRYING TO WORK ON MAKING THIS HAPPEN, IF YOU KNOW OF SOMETHING GOOD, LET ME KNOW. THERE ARE ALSO EXCELLENT BOOKS. I'VE USED A LOT OF CONTENT AND DIAGRAMS FROM THESE. BULLETPROOF SSL AND TLS WILL GIVE YOU A LOT OF CONTEXT ABOUT TLS THAT YOU NEED TO KNOW FOR TLS TO BE RIGHT. THERE'S THE-TANGLED-WEB, WHICH IS A REALLY GOOD BOOK ABOUT WHAT'S WRONG WITH THE MAKE IT BETTER. THERE'S LVH WHO IS GIVING TWO TALKS TODAY. INTERNET AND HOW IT HOPEFULLY HOW YOU CAN HE HAS WRITTEN A BOOK CALLED CRYPTO 101 WHICH IS AN EXCELLENT BOOK FOR CRYPTOGRAPHY FOR DEVELOPERS WHO DON'T KNOW ANYTHING ABOUT IT. SO I SUGGEST STARTING THERE. SO I KNOW IT LOOKS SCARY. I WOULD SAY BE BRAVE. DON'T BE AFRAID TO LEARN. HELP US OUT AT THE CRYPTOGRAPHY PROJECT. WE'RE ALL [INAUDIBLE] PEOPLE. SO HOP ON TO TLS, GO TO THIS CHANNEL AND TALK TO US. THANK YOU. ANY QUESTIONS? >> SO WE HAVE A FEW MINUTES FOR QUESTIONS. SO IF YOU'VE GOT ONE, PLEASE STEP FORWARD. >> AUDIENCE: WHY IS IT BAD TO TRUST AN EXPIRED CERTIFICATE. >> I'M SORRY. CAN YOU REPEAT? >> AUDIENCE: WHY IS IT BAD TO TRUST AN EXPIRED CERTIFICATE? LIKE WHY CAN'T YOU TRUST A CERTIFICATE THAT'S >> BECAUSE THE CERTIFICATE IS APPROVED. THE SITE WAS ACTUALLY OWN THE BY THE PERSON EXPIRED? WHO WAS SUPPOSED TO SERVE IT. AND AN EXPIRED CERTIFICATE MEANS THAT WHAT IF THE OWNERSHIP CHANGED. IT'S JUST NOT SAYING THE SAME THING ANYMORE. SO THANK YOU FOR YOUR QUESTION. >> AUDIENCE: I GUESS NOT REALLY A QUESTION BUT ANOTHER ALTERNATIVE TLS AND SSL LIBRARY IS LIBERATE SSL STARTED BY THE OPEN BSD GUYS. THAT ONE IS ALSO REALLY PRETTY GOOD, AND THEY'RE TAKING THEIR OWN PHONETICAL LOOK AT THEIR CODE BASE AND TAKING IT TO SSL. SO THAT'S A VERY GOOD PROGRESS. >> THANK YOU. DO WE HAVE MORE TIME FOR MORE QUESTIONS? ALL RIGHT THEN. I GUESS THAT'S THAT. THANK YOU. [ APPLAUSE ]