The Sorry State of SSL
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 117 | |
| Number of Parts | 119 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/19983 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Berlin |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
CodeInternetworkingRight angleComputer animationLecture/ConferenceSource code
00:42
Sign (mathematics)LogarithmLink (knot theory)Socket-SchnittstelleTransportschichtInformation systemsWeb browserMathematical singularityServer (computing)Open setValue-added networkMetropolitan area networkWeb serviceInternetworkingPublic key certificateOnline helpOrder (biology)InformationClient (computing)Ocean currentChainElectronic signatureTheory of relativityStatement (computer science)Row (database)Endliche ModelltheoriePatch (Unix)Distribution (mathematics)Basis <Mathematik>Web browserCASE <Informatik>Goodness of fitInstance (computer science)EncryptionData compressionNumberServer (computing)WindowCellular automatonINTEGRALPasswordProjective planeSoftwareMathematicsPlastikkartePoint (geometry)Particle systemComputer fileRule of inferenceSet (mathematics)Physical systemIterationMultiplication signIntegrated development environmentRandomizationInformation securityDifferent (Kate Ryan album)WordStandard deviationTransport Layer SecurityRevision controlSinc functionBeat (acoustics)Product (business)Link (knot theory)Metropolitan area networkOpen sourceState of matterCryptographyFamilyMathematical analysisVideo gameAuthorizationBitGroup actionLogical constantNetwork topologyKey (cryptography)MultiplicationFigurate numberComputer iconLie groupOperator (mathematics)Identity managementWeb 2.0DatabaseMereologyProcess (computing)Software bug
09:32
Suite (music)Ordinary differential equationData Encryption StandardReal numberKey (cryptography)Message passingCodeTotal S.A.Multiplication signSoftwareBitClient (computing)Symbol tableServer (computing)Graphics tabletStreaming mediaCryptographyAsynchronous Transfer ModeContent (media)GoogolBlock (periodic table)1 (number)Vector spaceAreaFlow separationEndliche ModelltheorieEncryptionPoint (geometry)Exterior algebraPublic-key cryptographyWeb browserTerm (mathematics)Hash functionPrice indexDifferent (Kate Ryan album)Axiom of choiceConnected spaceSurfaceObject (grammar)Motion captureInformation securityKey (cryptography)TelecommunicationOrder (biology)Control flowMessage passingState of matterComputer configurationReading (process)Data integrityAuthenticationWave packetForcing (mathematics)Service (economics)INTEGRALComputer clusterTraffic reportingFunctional (mathematics)Black boxSymmetric matrixRow (database)Maxima and minimaPower (physics)WeightWindowCodeConvex setPrimitive (album)FinitismusMortality rateOvalPurchasingProgrammable read-only memoryFamilyPixelCuboidTransport Layer SecuritySemantics (computer science)Computer hardwareOperator (mathematics)Similarity (geometry)Total S.A.MultilaterationCiphertextDefault (computer science)Software bugContext awarenessCollisionStream cipherSymmetric-key algorithmVariety (linguistics)TupleComputer fileGoodness of fitSuite (music)RSA (algorithm)DeciphermentInterior (topology)Single-precision floating-point formatComputer animation
18:21
WordReal numberSoftware testingValue-added networkMetropolitan area networkSuite (music)Client (computing)Process (computing)Peer-to-peerSet (mathematics)Physical systemInformation systemsRed HatService (economics)MassWindowRight angleInformation securityOpen setWeb browserDifferent (Kate Ryan album)AlgorithmFunctional (mathematics)Cycle (graph theory)Default (computer science)CASE <Informatik>System callVideo gameElectronic signatureSource codeChaos (cosmogony)Sign (mathematics)Directory serviceMilitary basePublic key certificateFrustrationFormal verificationHome pagePhysical systemFamilyWeb pageException handlingKey (cryptography)Client (computing)State of matterBitEncryptionFigurate numberForestComplex numberOperating systemSoftware testingSurfaceContrast (vision)Uniform resource locatorTransport Layer SecurityProcess (computing)Mathematical analysisSimulationSchlüsselverteilungRow (database)ConsistencyAssociative propertyPosition operatorSoftware developerPoint (geometry)Stress (mechanics)EmailServer (computing)Ultraviolet photoelectron spectroscopyOperator (mathematics)Projective planeMedical imagingTheory of relativityDerivation (linguistics)Group actionPrice indexDisk read-and-write headMultiplication signWebsiteNeuroinformatikResultantString (computer science)Computer fileLimit (category theory)Inverter (logic gate)Shape (magazine)Electronic mailing listWordPlanningSuite (music)National Institute of Standards and TechnologyRootConfiguration spaceData storage deviceAuthorizationDatabaseDrop (liquid)RSA (algorithm)Order (biology)Speech synthesisJava appletAsynchronous Transfer ModeAuthenticationAdvanced Encryption StandardBlock (periodic table)AverageFunction (mathematics)ImplementationMessage passingData Encryption StandardCryptographyView (database)Validity (statistics)ChainStructural loadCommunications protocolDuality (mathematics)MereologyComputer animation
27:11
Software developerPort scannerGoogolComputer configurationSet (mathematics)Fundamental theorem of algebraMeta elementArmBootingInternetworkingMaxima and minimaCountingCAN busStandard deviationInformation securityFundamental theorem of algebraDefault (computer science)Direction (geometry)Data conversionParticle systemNegative numberEmailLink (knot theory)Multiplication signWeb pageConnected spacePhysical systemFood energyServer (computing)InformationUniverse (mathematics)Level (video gaming)Content delivery networkTransport Layer SecurityHome pagePublic key certificateUtility softwareWeb browserGroup actionRadical (chemistry)SequenceWordComputer configurationDirect numerical simulationBuildingPattern languageService (economics)Library (computing)Similarity (geometry)Extreme programmingSoftwareExpressionQuicksortOrientation (vector space)CASE <Informatik>MathematicsProfil (magazine)PasswordMedical imagingRule of inferenceStandard deviationThumbnailCodeSystem callAssociative propertySpeech synthesisPerfect groupSoftware testing1 (number)Formal verificationGame controllerMatching (graph theory)Pulse (signal processing)Personal digital assistantProcess (computing)Computer animationEncryptionClient (computing)2 (number)Module (mathematics)DatabaseOnline chatTwitterSoftware bugCommunications protocolAuthorizationGoogolInternet service providerRoutingMetropolitan area networkWebsiteRootQuery languageXML
36:00
Open setDivision (mathematics)AverageWeb serviceServer (computing)Total S.A.CodeClient (computing)Uniformer RaumMetropolitan area networkPort scannerImplementationSoftwareSystem callGroup actionCryptographyAuthorizationKeyboard shortcutFormal verificationTransport Layer SecurityClient (computing)Parameter (computer programming)Connected spaceImplementationService (economics)Level (video gaming)Projective planeEncryptionLibrary (computing)MeasurementStandard deviationFront and back endsCodeModule (mathematics)Software frameworkEvent horizonSoftwareGroup actionIdentity managementInformation securityState of matterData compressionSubsetPauli exclusion principleWritingServer (computing)AbstractionLatent heatMobile appWordFreewareWeb 2.0Communications protocolPublic key certificateMomentumRevision controlConfiguration spaceComputer iconMultiplication signBitInterpreter (computing)Associative propertyOnline helpSolid geometryObservational studyDecision theoryVideo gameDomain nameDefault (computer science)Software bugCASE <Informatik>Metropolitan area networkPattern languageEqualiser (mathematics)QuicksortGraphics libraryReal numberPoint (geometry)Regular graphCellular automatonCategory of beingBit rateNormal (geometry)Element (mathematics)Formal languageHypermediaUniverse (mathematics)SummierbarkeitMereologyTwitterInstallation artFigurate numberProcess (computing)MassInstance (computer science)Particle systemExterior algebra
44:50
XMLComputer animation
Transcript: English(auto-generated)
00:15
So, hi, I'm not Hynek, but Hynek, and you may know me from the internet where I look
00:22
like this, and I'm squatting most of the Hynek accounts all over the internet. Other places you may know me from is here, yes, I just heard you're Python veterans, and when I'm not doing even that, I'm doing infrastructure at Varo Media, which is a small
00:45
but friendly and German web hosting company down in Potsdam, just a few train stations away from here, but I'm not here to talk about myself. I'm here to tell you that those shiny icons that promise you that you're safe because of military-grade encryption are a lie.
01:00
So, this statement may have been a bit more controversial a few years ago before Mr. Snowden, before the current onslaught of OpenSSL bugs, it feels like every week is something new, but I assure you those problems are much, much older.
01:20
We knew about the sorry state like 10 years ago, but nobody cared, because we were just sinful hat-wearing nerds. TLS was just there in our browsers, OpenSSL was open source software, so what could possibly go wrong? The problem is that you really need to know how things fit in together and how everything
01:43
is working in order to assess the risks, because there are always risks, and how to minimise them, because you can do much more damage than any bug in OpenSSL ever will if you just repeat some very popular mistakes that are done every day. So before we get into those, let me introduce you to the only link you will have to write
02:04
down today. Every other link, every other project, every other concept will be there. So just for now, lay back, relax and enjoy the talk, and we will start at ground zero. Why is this a state of SSL story, and what actually is SSL?
02:26
And what the hell does it have to do with TLS? And I think this question is best answered with a short history lesson, because everyone loves history lessons, and our particular one starts in the mid-90s when Netscape started to thinking that it would be nice if entering your credit card number on the internet
02:44
would not entail people buying drugs out of your pocket. And so they introduced SSL 2, which was completely host, as the basis for HTTPS, where the S is standing for secure, not SSL.
03:00
They fixed the worst parts a year later in SSL 3, and another three years later, and after a brief battle with Microsoft, it finally became a true IETF standard, and it was renamed to TLS, transport layer security. So just to reiterate, SSL is a product from Netscape from 1996.
03:26
TLS is an internet standard for 15 years now. So basically, I tricked you in here with the name, but since everybody knows that all iterations are always awesome, and I wanted to reach everyone I could, so I used the
03:40
most used keyword. So if I had to trick you in here, I hope you learned the first thing today and will not say SSL in the future anymore. So 2006 and 2008, the widely ignored TLS 1.1 and 1.2 have been released, they both fixed some serious problems, they added really nice features, but nobody cared.
04:00
Fast forward to last year, where for some totally random reason, people start scrutinizing our security habits again. And it turns out what I found was not entirely good. So for example, all browsers had supported only TLS 1 until 2013, so TLS 1 from 1999.
04:22
But the discoveries of 2013 changed everything. The times were just saying that something contains SSL or TLS, that it would be not And you really need to know roughly what you're doing, because this technology has really sharp edges still, I hope this will change in the near future, but for now you have
04:43
to know what you're doing and how things fit together. So what does TLS actually want to provide you with? So there's peer identity using certificates. You can verify when you connect to a host, who this host is, and not some group would trick you into connecting to their own server pretending to be you.
05:02
So that protects you against man-in-the-middle or MITM attacks. Then there's confidentiality, which is basically encryption of the network traffic, which means that people can't eavesdrop on your passwords, secrets, and everything. This is what most people think about when they hear cryptography, TLS, SSL, but it's
05:23
only a third, because the third thing is integrity, which ensures that you can detect if TLS records get lost, mangled, or arrive multiple times, which is just as important as the other two things. So now we know roughly what we are working with. Let's see how to use those and explain further details along the way.
05:44
So after this part, you will know what the smells of poor TLS usage are and what to avoid. And we will start with servers. And unless noted, I'm sticking to OpenSSL throughout the rest of this talk, because that's what you will be most likely using, especially on servers.
06:01
And if you're deploying servers, it's more or less your duty to ensure the best possible security for users, because they can neither see nor affect your own setups. So the first step is to use at least halfway up-to-date software. And if you deploy anything other than this today, you are being negligent, lazy, and
06:22
stop doing so. But I'm generally assuming that you are using some distribution which backports security patches, because unless you don't have that, there's no way you use anything older than the very newest versions, else new versions come out for a reason, especially for OpenSSL.
06:40
So if you compile yourself, you have to stay on top of it unless you want a bleeding heart. So the first thing you do if a client connects to you is that you send them your certificate, which says who you are. In order for the client to actually believe what the certificate says, it has to be signed
07:00
by a trusted third party, which is called a certificate authority or a CA. So the set of all CAs, the client trust, is called a trust database. And it's located either in a browser or in the operating system, depends on which browser you're using or what software in general you're using.
07:23
So to prove that this certificate is actually yours because you're sending it out to everyone who ever connects, a secret key belongs to each certificate, which in turn is used for signatures, which in turn can be verified using a certificate.
07:40
So you can prove that you're actually in the possession of the secret key and thus that you can be trusted with the certificate you have just sent to the client. Your job now is to make your certificate set up trustworthy. Because your TLS is worthless, there's no way for the client to determine who you
08:04
actually are. And you will not get a certificate signed directly by a trusted third party, but you will get a so-called chain file along with your certificate. So for example, in this case, the trusted CA, edge trust, signed some certificate for
08:23
Komodo, which in turn signed some other Komodo certificate, which in turn finally signed my certificate. So whenever a client, in this case, is a homepage, so a browser connects, it will receive all three certificates and then figures out the path to the secure one.
08:45
So take care of the trust chain. Forgetting chain certificate is a typical rookie mistake. Ensure the certificate is valid for a host name of your server. And of course, make sure that your certificates are not expired, because that's kind of embarrassing.
09:03
So disable SSL2. Chances are that's not necessary, but for instance, Apple's SSL, OpenSSL still needs that. Not that I would be suggesting that deploying servers on OS X is a good idea, because it's not. Don't do it. If you don't have to support Windows XP, you can also drop SSL3.
09:22
And finally, disable TLS compression to avoid crime attacks. So the first and the last usually is patched into OpenSSL, so you don't have to do it yourself, but you have to verify that it's actually happening. So the next objective is to configure your cipher suite such that every client gets
09:42
the best possible encryption. And a cipher suite is just a tuple of various cryptographic primitives that are used to secure a connection. And ultimately, the server has the last say which one is used, so use this power for good. And we'll start with cipher ints themselves, because they're easiest to explain. Just imagine them as black boxes that take plaintext data in, and a secret key.
10:07
And they give you ciphertext back, which should be indistinguishable from random data. So TLS ciphers are symmetric. That means that if you want to decrypt your ciphertext, the relevant function of the cipher
10:21
needs the exact same key. This will be important later on. This is pretty much straightforward. It gets a bit more complicated, because most ciphers are block-oriented. That means they operate on a certain block size, usually 128 bits nowadays. So you can't just put a 1GB move into it and wait for the ciphertext to come
10:41
out on the other end. If the data is bigger, you have to chop it up. And if it's smaller, you have to pad it. So in practice, you usually do both. The most common way to do that is nowadays still so-called cipher block-chaining, or CBC, which unfortunately has been implemented very poorly in TLS, which bestowed us with
11:03
a wide variety of attacks and problems, Beast being the most famous one. So they have been fixed in TLS 1.1, but you may remember what people did to TLS 1. Ignore it. So other alternatives, which have been employed, actually, are client-side fixes.
11:22
Every browser is full of fixes for all possible bugs that may be encountered on a server. And stream ciphers, like RC4 in the past and Charger 20 in the hopefully near future. And finally TLS 1.2 brought a shiny new mode called the Galois Counter Mode, which does
11:40
much more in chopping and padding, but more on that more later. So now we know what a cipher is. So which one to use? And this is a question of a lot of contention, and the correct answer is none. But sourcing some practical opinions, I'm going to say that the best current ciphers are
12:02
AES 128 in Galois Counter Mode, and the stream cipher ChaCha 20 from Dan Bernstein. And AES in GCM is really great in hardware, and ChaCha on the other hand is really good in software. So ideally it supports both and let the client decide which one to use, which is
12:20
exactly what Google does. Unfortunately it's not available to us mere mortals yet, so AES in GCM it is for now. But even for the latest Safari and IE browsers, you still have to fall back to AES CBC. It's the same cipher, just a different block mode. And it's completely fine on TLS 1.2.
12:41
So if you don't trust Intel's AES GCM chips because they are back door by all the agencies, you can still use this as a favorite cipher. It's not a problem. It's just, yeah, it's a bit slightly slower. But it's absolutely terrible on TLS 1.
13:00
So you don't have really any choice here other than hoping that the client contains fixes for their mode-based attacks. So if you need to support ancient clients like Windows XP, I would suggest to use triple less, which is decent. So decent in the sense that it's secure enough. However a three means that the AES cipher is used three times.
13:21
So you can imagine how fast that one is. And that's it. You don't need anything else to support everything you may encounter on the net. And we especially vary of the following ones. Export ciphers have been intentionally weakened in times when the export of cryptographic
13:44
software from the US was severely restricted. So these ciphers are back door by design. What's also not usable anymore is DES, which is not, as far as I know, back door, but it uses 56-bit keys and it can be brute forced without much effort.
14:05
And finally, there's my little favorite called RC4, which just seems to be a bit more complicated, but in reality it really is not. While some people are still claiming that it is the silver bullet for all mode-based problems, all notable cryptographers I know of have been suggesting for years
14:24
that RC4 may be flawed in ways that natural agencies may be able to decrypt it. And people with access to the Snowden files have finally confirmed the suspicion last year.
14:40
So, but it's fast, am I right? In order to encrypt and decrypt ciphers need a key. And as we've already established, we use symmetric ciphers. So you need the same key for both operations. So we need a way to agree on encryption keys over a yet-to-be-encrypted connection,
15:04
which kind of sounds like a chicken-egg problem. Unfortunately, meth came to the rescue and gave us several ways to establish keys over an insecure connection without actually leaking them. So three of them are currently widely deployed and the probably most famous one is RSA, which is not just a company that took several bags of money from the NSA
15:24
but also a public-key cryptosystem. So you have a public key and a private key, public key for encryption, private key for decryption. Simple. It is fast. That's why ops really like it. But as soon as the secret key bleeds out of the server, all future and past
15:42
communications become plain text to the attacker. We say it lacks perfect forward secrecy or that it is not PFS. And this bears really repeating. It's one court order, one CVE, or one server break-in. It's all it takes such that the thief can decipher everything they've captured,
16:02
capture, or ever will capture. And there's no way for you to know whether this is happening. Then there's the ephemeral Diffie-Hellman, which is PFS but slow. It has been around a while, but people were reluctant to deploy because slow.
16:22
Fortunately, now we have ECDHE, which is both fast and PFS. Unfortunately, it's still not completely, fully, widely supported, but we are getting there. Now, do everything humanly possible to ensure perfect forward secrecy for as many clients as possible.
16:42
I find it even more important than using the right cipher. And for that, you will have to support both DHE and ECDHE. And since ECDHE is faster, I would suggest that you prefer it. Use RSA only as the last option, only if you have to. Finally, message authentication codes, or MACs, are used for message integrity.
17:04
So messages in TLS context just means a TLS record. There's a lump of data that you sent out and received and worked on. MACs are not TLS specific. And they combine some magic crypto dust with shared secret keys to ensure both the integrity and the authenticity of single messages.
17:24
So we know that this exact message, as we have it, was sent by the person who knows the shared secret key in that order. And TLS uses a so-called keyed hash mag, or just HMAG by default. So you may have heard these terms, so maybe now things are kind of falling into place.
17:43
And before that, SSL used something similar but different. If your connection is secure with a traditional cipher, you can even define the hashing function that it's going to use for the HMAG. And there's nothing you can really do wrong,
18:00
like dangerously wrong. But I like to disable MD5 HMAGs because they really irk me. It doesn't suffer from the usual MD5 collision problems like the vanilla MD5, but it's MD5 and I like short cipher lists. Finally, TLS 1.2 introduced the possibility
18:20
that ciphers bring their own message authentication. And this is where the aforementioned GCM is interesting because this block mode has message authentication built right in so it's not an additional operation. It is handled within the encryption and decryption. So, finally, if your list does not contain only strong PFS ciphers,
18:43
make sure to configure your server that its own cipher preferences have a higher priority than the client's. Because the most up-to-date TLS implementations on both sides won't buy you anything if the client sends a list with RSA triple DES at the top and you begin to comply, although you could have had ChaCha 20
19:03
or whatever the future brings. And there are actually downgrade attacks that can make such things happen. So, you're basically done. If you do what I've told you on the past slides, you're fine and way ahead of the average.
19:21
Everything else is just minutia. However, you have to test your setup. I guess there's really some confusing stuff going on like on RHEL 6.5 or CentOS 6.5, the OpenSSL does support ECDHE. However, their Nginx has been compiled against an older OpenSSL
19:42
which means that it does not expose it to the clients. So, if you just look on the server and play with your cipher strings, you will have the impression that everything is fine, but from the outside, it's actually not. So, you always have to test your system from the outside. And if your server is just HTTPS,
20:02
which I'm going to assume, it's your lucky day because then you can just use the excellent SSL server test from Qualys and I'm going to just show you the output from my homepage and help you to just read the results. And I would like to stress that they test many more things
20:22
that I'm going to talk about, but I'm very tight on time anyway, but do the basics, get back to the page and make sure as much as possible is green. Always aim for an A+. It's not that difficult. So, certificate. This one is valid for my homepage both with and without the www.
20:45
It's valid from this March until next May. And the key is a 4K RSA key, which means that it uses RSA for cryptographic signatures, not for key exchange. It's the same algorithm, but a completely different use case
21:02
with different implications. So, other possibilities are DSS, which nobody uses, and ECDSA that is gaining some traction but is still under-supported by both clients and CAs. So, if you want to be avant-garde and deploy ECDSA, you have to pay a lot more for your certificates and you have to do a dual certificate setup
21:22
like Google is doing right now. So, as for RSA keys, 4K is the current state-of-the-art, so if you're deploying new certificates, you should aim for that. 2K is barely enough, but most common right now. 1K is a serious security problem. So, it was issued by Komodo,
21:42
and they signed it with SHA-2, which is nice because, again, this is what you should strive for. Most certificates nowadays are still signed with SHA-1, which has been deprecated even by the NIST. So, yeah, it has no extended validation because I think this is just a huge racket to make loads of money,
22:01
and it's not revoked, it's trusted, yay. Protocols. Ensure always that TLS 1.2 and 1.1 are active, and SSL 2 inactive. If you're in an unlucky position like I am, you have to keep SSL 3 along but if you can't, drop it.
22:23
And now, finally, for cipher suits. Here it is. The currently best widely supported cipher string you can have, and we'll look at it in detail. So, it uses the fast and forward-secure ECDHE for key exchange,
22:41
the OKRSA for signatures, which is predefined by the certificate. You cannot configure this one. The cipher itself, AES128 in GCM mode. Nice, nice. And SHA-256, which is a SHA-2 algorithm,
23:02
is used for key derivation on a TLS handshake. If there would be an external HMAC, so if we weren't using GCM, this function would also be used for would be used for the HMAC.
23:21
So, please note that the server strictly prefers forward-secured ciphers over non-forward-secured one. And even say so that the server prefers the order. This is really important.
23:41
Again, if you can, drop RSA. You only need it for old windows. However, this is a rather privileged view. For browsers, compared to many mail server setups and old Java versions, IE6 can look like a sweet dream. So, you have to look what works for you and what your clients are.
24:01
And speaking of clients, let's talk about them. And it turns out, the browsers aside, the client side of TLS is in the worst shape of all. Which is kind of surprising because they have only one single job. Verify. Verify the certificate the server sends you. Is it valid or is it expired?
24:20
Does the trust chain validate? And finally, is the certificate valid for the host you want to actually connect to? Especially hostname verification. It's in such a pathetic state that there's an actual scientific paper about how client software, except browsers, does not verify hostnames. And unfortunately,
24:40
OpenSSL has no little part in the status quo. So, we'll start with the trust chain. First thing is that certificate verification is opt-in. And guess what? You have to tell OpenSSL explicitly which CAs you trust. Unfortunately, trust stores are highly platform-dependent.
25:01
Every OS has it elsewhere. Fortunately, there is a function call that on properly configured computers will load the default trusted CAs from compiled in PATH. But for some odd reason, this function is completely undocumented in OpenSSL.
25:24
And it also only works with file- and directory-based trust databases. So it will not work with Windows or OS X. At least not with the OpenSSL that's shipped with OS X. So, as if OpenSSL's obstacles weren't obstacle-ish enough,
25:41
the operating system vendors decided to make our life even a bit more miserable by not installing them by default. So, make sure you install your trust databases before you try to use them. So for FreeBSD, it's CA root NSS. And for both EBN and Red Hat, it's CA certificates.
26:01
Some consistency, finally. On OS X, you can either use Apple's ancient OpenSSL, which you shouldn't, and figure out the quirks of their patched-in trust ablation agent which cost two weeks of my life, or you go for Homebrew,
26:20
which will give you the latest OpenSSL. And on installation, it will create a copy of the system trust database and use that in the future. And then it works with the API call I mentioned before. It's not perfect, but it's about as good as it will get.
26:42
For Windows, there's Windsor store. I see the author of it even sitting here. And finally, if you want to dodge the bullet completely, you can just use Serify, which is a Python package of Mozilla's trust database. And it kind of belongs to the requests project,
27:02
but it has been externalized, and it now is under good support. So, ops don't really like it when you use your own trust database, but if you don't have the knowledge and energy to figure out all these cases, you may want to just go the cheap way.
27:22
So, hosting verification. I say it's even worse. And the problem here is because OpenSSL just says you. There's frankly absolutely no assistance from OpenSSL whatsoever to verify whether a certificate is valid for a hostname.
27:41
Nothing. There isn't even any documentation on that because they just consider it out of scope, so whatever. So everyone has to implement it on their own using RFCs and bogus advice from StackOverflow. And of course, it's raining security bugs, and Python was involved too in one, at least one, one that I know of.
28:01
So, but failing to verify certificates and hostnames has very grave consequences because it makes you extremely susceptible to MITM attacks. If you don't verify anything, which is the default behavior, if you don't anything special, I can pretend to be your Google with a self-signed certificate I can create under a second.
28:20
If you verify the certificate, because you found somehow the API calls, but you don't verify the hostname, I can still be your Google because it's perfectly trust... I can use just my own certificate from my own homepage, which will work because it's perfectly trustworthy.
28:40
It's signed by a trustworthy CA, but not for the hostname, but you will not know because you didn't look. So again, verify all the things. If there's only one thing you take away from this talk is that if you write TLS client software, always verify everything. Any other way, you are pretending a level of security
29:03
which is just not there. And the rest is just mundane. You limit your acceptable ciphers to strong ones for times of poorly configured servers. I heard there are some out there. And disable SSL too. That's all. And yet, so few do it. It's a perfect storm of ignorance on one side
29:22
and operating systems and OpenSSL making it unnecessarily hard on the other. And let's continue with the users. The weakest link of the security chain. Because they can make everything fall apart no matter how much the rest of the stack tries to keep them secure.
29:41
And it starts with fundamental misconceptions about what TLS even wants to do for you. So for example, it's nice that your connection to your chat or email server is encrypted with the latest and greatest cipher. It's awesome. Keep doing it. But, if the other person you're talking to is connected using a plaintext connection or some intermediate server is compromised
30:02
your confidentiality level for this conversation is exactly zero. And since, again, there's no way for you to know whether this is happening you have always to assume the worst. TLS only offers security between direct hosts. And if you additionally need confidentiality for an end-to-end conversation
30:23
you will need an end-to-end protocol like PGP for email or OTR for chat. And then there's the problem that some data cannot be encrypted. For example, DNS queries. If you're surfing, for example, a job site at work
30:43
over HTTPS there are still many ways for IT to find out that you're doing just that. There are traffic patterns, DNS queries there's a lot of stuff going on that you cannot hide. You will have to use a VPN or something similar. But a VPN routes all your traffic through the network of your VPN provider so you better make sure that you trust them.
31:02
And this applies even more, even stronger to content delivery networks because they do the TLS termination for you they see the traffic in clear text. So in other words Fastly could sniff out all your PyPI passwords if they wanted to. And this is another reason to never reuse passwords
31:22
because you never know what third party you may not even know about gets to see it. So next if you've ever clicked away something like this you may have been MITM'd. And the rule is pretty simple. Investigate the warning and then use your best judgement. So if the certificate is okay
31:41
but expired five minutes ago it's time for a snarky tweet but you're probably fine. If it's mostly okay but you notice circumstances for example a 2-state still doesn't properly support SMI in 2014 you're probably fine too I would avoid the snarky tweet
32:01
because you might get the ticket redirected to you. And again use your mind if you don't fully understand what's going on here just decline. Man in the middle attacks are probably much easier than you think especially in public networks all it takes is a rogue DHCP server.
32:23
So the next level of clicking mindlessly is if some crook tricks you installing their root certificate into your trust database because that means that every certificate that is signed by this crook CA will be considered trustworthy by your system or by your browser.
32:41
You will never ever see a warning again when they MITM you and sometimes it sounds more initial like on the iPhone it's called I think profiles or something like that if you install a profile you can get some CA trust changes too along the way
33:01
and will not really know. And even if the user doesn't screw up there's still a lot that can go wrong because the trust database isn't really under their control they usually can add things but they usually don't remove things or maybe they even can't remove things and there are some CA's that may cause some
33:20
level of discomfort to you. So for example this means that the Department of Defense of the United States of America can sign a certificate for any host name in the world and it will be trustworthy. This is not an American thing China is right up there and just as everyone else every single country in the world has some CA they can abuse for some
33:42
for some of their nefarious reasons so and it's also not unheard of CA's being hacked making fatal mistakes you may have heard of it I think it's like two weeks ago when this Indian CA started deploying Google certificates
34:01
or they are forced to cooperate with authorities and maybe they are just corporations whose priorities may not entirely match yours for example Microsoft is a CA, Google is a CA whatever it means to you but this whole system is just broken and speaking of broken
34:21
let's talk about Python now let's start with a simple rule of thumb as you've seen people love to screw up TLS so if it's somehow possible let battle-tested software do it for you put an Nginx in front of it, put an Apache in front of it there's a lot of information how to get it right
34:43
this stuff is just properly reviewed people use it all night, this is not true for some Python module, they just added some API calls because someone asked on it on a bug tracker but let's see anyway what to do we have basically two camps for TLS
35:02
we have the standard libraries SSL module and we have PyOpenSSL and we will start with included batteries which are pretty rusty in everything before Python 3.3 and due to backward compatibility requirements the default behavior in 3.4 is still terrible so for example hosting verification is still opt-in
35:22
although the code is there but it cannot be active by default because people would cry because they are badly deployed and TLS stakes would break that's a situation you wish for in Python 2 though because its coverage of OpenSSL APIs is very very poor, for example it's impossible
35:42
to write forward secure servers, so in other words you should never write servers with the standard libraries SSL module before Python 3.3 and it also lacks a bunch of options so you can't disable SSL 2 you can't disable
36:01
TLS compression stuff like this. Another drawback is that you are bound to the OpenSSL that your Python has been compiled against, so if you need a more recent OpenSSL or anything you will have to recompile your whole Python your whole Python interpreter what's also completely
36:21
missing from Python 2 is hosting verification but unfortunately it's on PyPI so there is a way to do it for client software but hands up if anybody knew of that and have actually used it yeah it was very few hands and one of the hands actually implemented it
36:44
so PyOpenSSL it comes from a time when the standard libraries TLS support was even worse than what we have in 2.7 today and it runs on all relevant Python versions and although it has been a bit dormant over the course of time it still has a much much better
37:00
coverage of the APIs than the SSL module in Python 2 and more importantly a new project gave PyOpenSSL a new vigor after 10 years or so PyCast cryptography what is it? it's a bunch of Python people with more time and sense and a knack for bad life decisions that came together to
37:22
create a Python crypto library without fruit guns and eventually the Python cryptography authority or PICA in short has been formed around it and a side product of that were CFFI bindings which are PyPI friendly
37:42
and what's even nicer is that you can choose an alternative OpenSSL without any problems C code transport backends are in the works so we all get our heartbleeds our good or fail in Python 2 and what's really nice about the whole thing is that PyOpenSSL
38:01
could just throw out all the C code they've ever used it's now a pure Python project which is just building Python abstractions on top of a C API that's coming from elsewhere so it gave some real momentum after it languished for several years but again no hostname verification
38:21
so again help us on PyPI service identity will give you hostname verification plus some more obscure ways to verify the identity of a service which you will probably never use but they are defined in an RFC so there it is again opt-in you have to remember to use it and we will look now at the most
38:41
common frameworks and packages on how well behaved TLS citizens they are I'll start with service again so event land, g-u-ent, g-unicorn and tornado all suffer from the same problem they use the standard libraries SSL module therefore they cannot have PFS ciphers they cannot set connection parameters tornado could
39:01
theoretically on Python 3 but they don't g-u-ent has some code in place that will maybe arrive in the next future release but until then put an nginx in front of all of them twisted is probably one of the few legit reasons to come with TLS in the first place because it's useful to implement all kinds of protocols
39:21
so not just HTTPS but all these checkmarks are true only from 14.0 which was released a few months ago so you do yourself a favor don't use anything older and a little known fact is that twisted ships with a nice risky container so in other words you can deploy HTTPS web apps without putting anything in front of it
39:41
and still have a TLS support and nope deploying risky apps on twisted does not mean that you have to use callbacks or camel case it's all good so there's finally micro risky it's not Python specific so they just went and wrote some C code themselves that made them the masters of their own fate and indeed their implementation appears to be
40:01
fully featured and I would still always put an nginx in front of it but that's only because I have a general distrust towards using C code and associate you finally micro risky no sorry I've slipped yeah sorry sorry sorry
40:22
these diggers they're gonna stay as long as a certain PEP hasn't passed or as long as they don't port to Python 3 or to pyopmssl so client side eventland and gevent just as bad as before you can do better and tornado shows how they depend on
40:40
certify and they depend on the backports so you get all the verification by default they still can't set certain defaults because they are they didn't appear before Python 3.2 so twisted is a bit more complicated all the
41:00
low level stuff is there since 14.0 so you can write correct software what's currently missing is a proper endpoint it will do all the things by default but we are getting there um what's never getting get anywhere is zero lib 2 don't use it ever for any http actions they just cannot
41:21
get better instead use requests together with zero lib 3 um what's really nice is that it tries transparently to get the most out of it what's even possible so they will use pyopmssl if it's there and they will verify everything that's possible and they even
41:41
ship the 35 inside of it so let me sum it up quickly keep TLS out of Python if you can use requests for https queries use pyopmssl inside write your TLS service on twisted and if
42:02
you need low level TLS I strongly suggest to use pyopmssl because it's much better on Python 2 and it will follow you faithfully to Python 3 finally use the Python 2 standard library only as the last measure only for clients and use the relevant backports so
42:22
wrapping up why is it sorry? so it's sorry because people still say SSL although it's been obsolete for 15 years it's sorry because the implementations are terrible all of them it's sorry because users run outdated software click
42:42
certificate warnings away and are at the mercy of third parties yeah, forgot to click sorry um and those third parties let them down regularly so servers run completely outdated software that is configured completely poorly clients don't verify anything although it's their only job
43:01
and we're not talking about some obscure freeware here this January security researchers of IOactive have found 40% of tested banking apps to be suspicious to MITM attacks and it's sorry because Python is at the forefront of being terrible, the current state really is sorry, the title of this talk is not attention made, but there's hope so first
43:22
we care again, acceptance always the first step the TLS support got much better in Python 3 and there's even a PEP to improve retroactively in Python 2 so it's impossible to write secure software um, again we've got the PICA now
43:41
which is a bunch of really smart people plus me that has already adopted several cryptography related projects and it's supposed to be the one stop shop for solid crypto software for Python so we are really trying here but, help always means work too, so stop believing that the lock icon will keep you safe
44:01
do not click away certificates warnings be a critical user configure your servers properly install security updates immediately if you connect to servers, verify all the things and finally help us to get Python out of this mess um, fix your software fix your libraries
44:21
report bugs, help fixing these bugs there's really a lot to do and, there's that's all I had for you today I hope you learned something and more importantly are really eager to fix things now so, go out study the talk page, follow me on Twitter and get your domains from Varo Media thank you