 So, hi. I'm not Hineck, but Hineck, and you may know me from the Internet where I look like this, and I'm squatting most of the Hineck accounts all over the Internet. Other places you may know me from is here. Yes, I just heard the European veterans. And when I'm not doing even that, I'm doing infrastructure at Vario Media, which is a small but friendly 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. So, this statement may have been a bit more controversial a few years ago before Mrs. Snowden, before the current onslaught of OpenSSL bugs. It feels like every week is something new. But I'm sure that those problems are much, much older. We knew about the sorry state like 10 years ago, but nobody cared. Because we were just tinfoil 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 is working in order to assess the risks, because there are always risks, and how to minimize 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 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 state of SSL story and what actually is SSL? 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 the credit card number on the internet would not entail people buying drugs out of your pocket. And so they introduced SSL2, which was completely host, as the basis for HTTPS, where the S is standing for secure, not SSL. They fixed the worst bugs a year later in SSL3. 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. TLS is an internet standard for 15 years now. So basically, I tricked you in here with the name. Since everybody knows that literations are always awesome, and I wanted to reach everyone I could, so I used the most used keyword. So if I had to trick you in here, I hope you learned a 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. 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. But the discoveries of 2013 changed everything. The times were just saying that something contains SSL or TLS, that it would be a not are gone. 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 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. 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 on your passwords, secrets, and everything. This is what most people think about when they hear cryptography, TLS, SSL. But you think it's only a third, because the third thing is integrity, which ensures that you can detect if TLS records get lost, mangled, or arrived 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. 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 open SSL throughout the rest of this talk, because that's what you're most likely using, especially on servers. 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 older than this today, you are being negligent, lazy, and 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 open SSL. 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 to the client to actually believe what the certificate says, it has to be signed by a trusted third party, which is called a certificate authority or a CA. So the set of all CAs that 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. 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. And 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 if there's no way for the client to determine who you 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 at trust signed some certificate for Komodo, which in turn signed some other Komodo certificate, which in turn finally signed my certificate. So whenever a client in this case is at home page, so a browser connects, it will receive all three certificates. And then figures out the path to the secure one. So take care of the trust chain. Forgetting chain certificate is a typical rookie mistake. Ensure the certificate is valid for the host name of your server. And of course, make sure that your certificates are not expired, because that's kind of embarrassing. So, disabled SSL 2, chances are it's not necessary, but for instance, Apple's SSL, open SSL stills need that. I would be suggesting that deploying servers on OS 10 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 SSL 3. And finally, disabled TLS compression to avoid crime attacks. So the first and the last usually is patched into your open SSL, 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 Cypher suite such that every client gets the best possible encryption. And a Cypher 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. I will start with Cypher themselves, because they're easiest to explain. Just imagine them as black boxes that take plain text data in and a secret key. And they give you Cypher text back, which should be indistinguishable from random data. So TLS Cypher is asymmetric. That means that if you want to decrypt your Cypher text, the relevant function of the Cypher needs the exact same key. This will be important later on. This is pretty much straightforward. It gets a bit more complicated, because most Cypher's are block-oriented. That means they operate on a certain block size, usually 128 bits nowadays. So you can't just put one gigabyte moving into it and wait for the Cypher text to come 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 Cypher block chaining, or CBC, which unfortunately has been implemented very poorly in TLS, which bestowed us with 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. Every browser is full of fixes for all possible bugs that may be encountered on a server. And stream cyphers, like RC4 in the past and Chacha 20 in the hopefully near future. And finally, TLS 1.2 brought a shiny new mode called the Galois Counter Mode, which does much more in chopping and padding, but more on it one later. So now we know what a Cypher 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 cyphers are AES-1.28 in Galois Counter Mode and the StreamCypher Chacha 20 from Dan Bernstein. And AES in GCM is really, really great in hardware, and Chacha on AES is really good in software. So ideally, it's super both and let the client decide which one to use, which is 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 latest Safari and IE browsers, you still have to fall back to AES CBC. It's the same cypher, just a different block mode. And it's completely fine on TLS 1.2. So if you don't trust Intel's AES-GCM chips, because they are backdoored by all the agencies, you can still use this as a favorite cypher. It's not a problem. It's just, yeah, it's a bit slightly slower. But it's absolutely terrible on TLS 1. 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 Desk, which is decent. So decent in the sense that it's secure enough. However, 3 means that the DS cypher is used three times. 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 cyphers have been intentionally weakened in times when the export of cryptographic software from the US was severely restricted. So these cyphers are backdoored by design. What's also not used anymore is DES, which is not, as far as I know, backdoored, but it uses 56-bit keys and it can be brute-forced without much effort. 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 multiple cryptographers I know of have been suggesting for years that RC4 may be flawed in ways that national agencies may be able to decrypt it. So, and people with access to the Snowden files have finally confirmed the suspicion last year. So, but it's fast, am I right? In order to encrypt and decrypt, cyphers need a key. And as we've already established, we use symmetric cyphers. So you need the same key for both operations. So we need a way to agree on encryption keys over yet to be encrypted connection, which kind of sounds like a chicken-act problem. But fortunately, math 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, but also public key crypto system. 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 people really like it, but as soon as the secret key bleeds out out of the server, all future and past 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, it's all it takes and such that the thief can decipher everything they've captured, captured, or ever will capture, and there's no way for you to know whether this is happening. Then there's the ephemeral Diffie Halman, which is PFS, but slow. It has been around a while, but people were reluctant to deploy it because slow. 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. Well, now do everything humanly possible to ensure perfect forward secrecy for as many clients as possible. I find it even more important than using the right cypher, 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 MEX, are used for message integrity. 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. MEX 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. 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 mark or just H mark by default. So you might have heard these terms, so maybe now things are kind of falling into place. And before that, SSL used something similar but different. If your connection is secure, the traditional cipher, you can even define the function, the hashing function that is going to use for the H mark. And there's nothing you can really do wrong, like dangerously wrong. But I like to disable MD5 H marks because they really hurt 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 of that ciphers bring their own message authentication, and this is where the formation 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, make sure to configure your server that it, sorry, that its own cipher preferences have a higher priority than the clients because the most up-to-date TLS implementations on both sides won't bore you anything if the client sends a list of with RSA triple des at the top and you obediently comply, although you could have had Cha Cha 20 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. Everything else is just minutiae. However, you have to test your setup because there's really some confusing stuff going on, like on REL 6.5 or CentOS of 6.5, the OpenSSL does support ECD-HE. However, their engine X has been compiled against an older OpenSSL, 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, which I'm going to assume, it's your lucky day because then you can just use the excellent SSL server test from our QALIS, and I'm going to just show you the output for my home page and help you to just read the results. And I would like to stress that they test many more things that I'm going to talk about, but I don't, 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 plus. It's not that difficult. So, certificate. This one is valid for my home page both with and without the triple W. It's valid from this March until next May, and the key is an RSA, it's 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 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 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, 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, and it's not revoked, it's trusted, yay. Protocols ensure always that TS1.2 and 1.1 are active, and SSL2 are inactive. If you're in an unlucky position like I am, you have to keep SSL3 on, but if you can't, drop it. And now finally, for cipher suits. Here it is. They're currently best widely supported cipher string. Okay, nice. And we'll look at it in detail. So, it uses the fast and forward secure ECDHE for key exchange, the OKRSA for signatures, which is predefined by the certificate. You cannot configure this one. Yeah, the cipher itself, AES128 in GCM mode. Nice, nice. And SHA-256, which is a SHA-2 algorithm, is used for key derivation on a TS handshake. If there would be an external HMAG, so if you weren't using GCM, this function would also be used for the HMAG. Yeah. So, please note that the server strictly prefers forward-secured ciphers over non-forward-secures one. And even say so that the server preferred order. This is really important. Again, if you can drop RSA, you only need it for old Windows. However, this is a rather privileged view for browsers, because 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. And speaking of clients, let's talk about them. And it turns out the browser's 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? Does the trust chain validate? And finally, is the certificate valid for the host you wanted to actually connect to? Especially hosting verification is in such a pathetic state that there's an actual scientific paper about how client software except browsers does not verify host names. And unfortunately OpenSSL has no little part in a 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. Every AOS has it elsewhere. Fortunately, there is a function call that will, 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. 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 OpenSSL that shipped with OS X. So, and as if OpenSSL's obstacles were an obstacle-ish enough, 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 privacy, it's CA root NSS. And for both EBN and Red Hat, it's CA certificates. Now, 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 oblation agent, which cost two weeks of my life. Or you go for Homebrew, which will give you a decent, the latest OpenSSL and on installation, it will create a copy of the system trust database and use that in a 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. Fine. For Windows, there's Windsert 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. It kind of belongs to the request project, but it has been externalized and it now is under good support. 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. So, house name 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 host name. 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 StackArrowFlow. And of course, it's raining security bugs, and Python was involved too in one, at least one, one that I know of. So, but failing to verify certificates and host names has very grave consequences, because it makes you extremely suspicious 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 a Google with a self-signed certificate I can create under a second. If you verify the certificate, because you found somehow the API calls, but you don't verify host name, I can still be a Google because it's perfectly trust, I can use just my own certificate from my own home page, which will work because it's perfectly trustworthy, it's signed by a trustworthy CA, but not for a host name, 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, which is not 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 it's able SSL too, that's all. And yet so few do it. It's a perfect storm of ignorance on one side and operating systems and open SSL making 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. 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 service encrypted with the latest and greatest cypher. It's awesome, keep doing it. But if the other person you're talking to is connected using a Plantex connection or some intermediate server is compromised, your confidentiality level for this conversation is exactly zero. And since again there's no way for you to know where 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, you will need an end-to-end protocol like PGP for email or OTR for chat. And then there's the problem of some data cannot be encrypted. For example, the NS queries. If you're surfing, for example, a job site at work 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. 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, Fastli could sniff out all your PPI passwords if they wanted to. And this is another reason to never reuse passwords, because you never know what third party you may not even know about gets to see it. So next, if you ever clicked away something like this, you might have been MITM. And the rule is pretty simple, investigate the warning and then use your best judgment. So if the certificate is okay, 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 two-stitch still doesn't properly support SNI in 2014, you're probably fine too. I would avoid the snarky tweet because you might get the ticket redirected to. And again, use your mind. If you don't fully understand what's going on here, just decline. Man in the middle of text are probably much easier than you think, especially on public networks, all it takes is a rogue DHCP server. 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 crooked CA will be considered trustworthy by your system or by your browser. You will never ever see a warning again when MIT MU. And sometimes it sounds more interesting. 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. It 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 cost some 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. And this is not 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 of their nefarious reasons. 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. Or they are forced to cooperate with authorities. And maybe they are just corporations whose priorities 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, 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 test the software, do it for you. Put an engine in front of it, put in a patch in front of it, there's a lot of information how to get it right. This stuff is just properly reviewed. People use it all night. This is not true for some Python modules. Just edit some API calls because someone asked on it on a bug tracker. But let's see anyway what to do. So we have basically two camps for TLS. We have the standard libraries SSL module and we have PyOgMS SL. And we will start with the included batteries, which are pretty rusty in everything before Python 3.3. And due to backward compatibility requirements, the default behavior on 3.4 is still terrible. So for example, hosting verification is still opt-in, although the code is there. But it cannot be active by default because people would cry because they're badly deployed. TLS stakes would break. That's a situation you wished for in Python 2, though, because it's coverage of open SSL APIs is very, very poor. For example, it's impossible to write forward secure service. 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 TLS compression, stuff like this. Another drawback is that you're bound to the open SSL that your Python has been compiled against. So if you need a more recent open SSL or anything, you will have to recompile your whole Python interpreter. What's also completely 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. So Py Open SSL. 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 coverage of the APIs than the SSL module and Python 2. And more importantly, a new project gave Py Open SSL a new vigor after 10 years or so. PyCa's cryptography. What is it? It's a bunch of Python people with more time and sense and a neck for bats life's decisions that came together to create a Python crypto library without food guns. And eventually the Python cryptography authority or PyCa in short has been formed around of it. And a sign product of that is CFFI bindings which are PyPy friendly. And what's even nicer is that you can choose an alternative Open SSL without any problems. Seeker transport backends are in the works. So we all get our hard bleeds and our good will fail in Python 2. And what's really nice about the whole thing is that Py Open SSL could just throw out all the C codes 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 host name verification. So again, help us on PyPI service identity will give you host name 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'll look now at the most common frameworks and packages on how well-behaved TLS citizens they are. We'll start with service again. So event land, G event, 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 theoretically on Python 3, but they don't. G event has some code in place that will maybe arrive in the next future release, but until then put an engine next in front all of them. Twisted is probably one of the few legit reasons to code with TLS in the first place because it's useful to implement all kinds of protocols. So not just HTTPS, but this 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 Whiskey container. So in other words, you can deploy HTTPS web apps without putting anything in front of it and still have ASTLS support. And no, deploying Whiskey apps on Twisted does not mean that you have to use callbacks or chemo case. It's all good. So that's finally micro-Wiskey. 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 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 open as using C code and so should you. Finally, micro-Wiskey. These diggers, they are going to stay as long as a certain PEP hasn't passed or as long as they don't port to Python 3 or to Biogmas SL. So client-side. Event-lange event, just as bad as before. You can do better and the radar shows how. They depend on certify and they depend on the back ports so you get all the verification by default. They still can't set certain defaults because they didn't appear before Python 3.2. Twisted is a bit more complicated. All the low-level stuff is there since 14.0, so you can write correct software. What's currently missing is a proper endpoint that will do all the things by default, but we are getting there. I was never getting anywhere as zero looked through. Don't use it ever for any HTTPS actions. They just cannot get better. Instead, use requests to get rid of 3. What's really nice of the request is that it tries transparently to get the most out of it what's even possible. So they will use PyOpenSSL if it's there and they will verify everything that's possible and they even ship with 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 PyOpenSSL inside it. Write your TLS service on Twisted and if you need low-level TLS I strongly suggest to use PyOpenSSL 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 back ports. So wrapping up. Cool. 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 certificate warnings away and are at the mercy of third parties. Yeah, forget to click sorry. 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. 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 suspicable to MITM attacks. And it's sorry because Python is at a forefront of being terrible. The current state really is sorry. The title of this talk is not attention weight but there's hope. So first be care again. Acceptance. Always the first step. The TL support got much better in Python 3 and there's even a PEP to improve retroactively in Python 2. So it's even possible to write secure software. Again, we have got the PyKa now 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 hope always means work too. So stop believing that the lock icon will keep you safe. 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. Fix your software, fix your libraries, report bugs, help fixing these bugs. There's really a lot to do and 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 comments from very media. Thank you.