SSl Error, what now?
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 |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 132 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 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 and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/44975 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EuroPython 201830 / 132
2
3
7
8
10
14
15
19
22
27
29
30
31
34
35
41
44
54
55
56
58
59
61
66
74
77
78
80
81
85
87
91
93
96
98
103
104
105
109
110
111
113
115
116
118
120
121
122
123
125
127
128
129
130
131
132
00:00
SoftwareTransport Layer SecurityArrow of timeCue sportsSlide ruleMultiplication signLine (geometry)Inheritance (object-oriented programming)Computer animation
00:39
Transport Layer SecuritySoftware developerCore dumpSoftware maintenanceModule (mathematics)Information securitySoftwareData managementPublic-key infrastructureError messageCryptographyRootFormal verificationNoise (electronics)Hidden Markov modelInformation securityCryptographyPointer (computer programming)Line (geometry)Link (knot theory)Level (video gaming)Formal verificationMultiplication signSoftware maintenanceEndliche ModelltheorieSingle sign-onSoftware developerBitFreewareTheory of relativityService (economics)Data managementView (database)Core dumpConnected spaceStack (abstract data type)Video gameRootIdentity managementComputer animation
01:59
Transport Layer SecurityMassDigital rights managementBitTransport Layer SecurityWebsiteWeb pageWeb browserEncryptionRankingLink (knot theory)2 (number)Graphical user interfaceCuboidMoment (mathematics)Graph (mathematics)Computer animation
03:25
Transport Layer SecuritySSLPulse repetition frequencyAdvanced Encryption StandardNetwork switching subsystemFirefox <Programm>Java appletCryptographyGoogolModule (mathematics)Network socketComputer hardwareConfiguration spaceInformation securityNumberCuboidWindowContext awarenessTransport Layer SecurityPlastikkarteInformationStandard deviationDatabaseLibrary (computing)Communications protocolEndliche ModelltheorieRevision controlLevel (video gaming)Flow separationEncryptionConnected spaceCASE <Informatik>InternetworkingOpen setField (computer science)Basis <Mathematik>Product (business)Core dumpPresentation of a groupCross-platformMultiplication sign1 (number)Pulse repetition frequencyBitLaceComputer animation
07:00
Transport Layer SecurityCryptographyInformation securityComputerComputer networkData integrityInformation privacySocket-SchnittstelleCore dumpStreaming mediaCommunications protocolAuthenticationServer (computing)Client (computing)Standard deviationTask (computing)InternetworkingPublic-key infrastructureDirect numerical simulationView (database)Connected spaceCommunications protocolSymbol tableTransport Layer SecurityEncryptionStandard deviationTelecommunicationRow (database)Database transactionMultiplication signDatabaseData integritySoftwareCryptographyEmailClient (computing)Presentation of a groupAuthenticationWordEndliche ModelltheoriePublic key certificateInformationCore dumpBitServer (computing)Green's functionVideo gameCombinational logicDifferent (Kate Ryan album)Information privacyCartesian coordinate systemSlide rulePlastikkarteEnterprise architectureFilm editingInformation securitySoftware maintenanceFile formatComputer animation
10:01
Parameter (computer programming)Transport Layer SecurityDirect numerical simulationNetwork socketError messageBlock (periodic table)Revision controlAliasingAddress spaceConnected spaceServer (computing)Parameter (computer programming)SoftwareFirewall (computing)Multiplication signEmailService (economics)Level (video gaming)Client (computing)EncryptionRevision controlCommunications protocolBlock (periodic table)TelecommunicationNumberField (computer science)BitMereologyData integrityError messageDirect numerical simulationInternet service providerCASE <Informatik>Different (Kate Ryan album)Electronic mailing listTransport Layer SecuritySuite (music)Computer animation
13:07
Error messageFunction (mathematics)Link (knot theory)RippingFlagComputer configurationHausdorff spaceSoftwareCore dumpRaw image formatComputer configurationServer (computing)Router (computing)Computer animation
14:01
Transport Layer SecurityFirewall (computing)Web browserWeb browserFirewall (computing)Direct numerical simulationVideo game consoleConnected spaceServer (computing)InformationPort scannerLevel (video gaming)Error messageWeb 2.0Computer animation
14:49
Transport Layer SecurityClient (computing)Direct numerical simulationRevision controlRandom numberServer (computing)Suite (music)EncryptionDataflowCommunications protocolParameter (computer programming)Error messageFunction (mathematics)Server (computing)Client (computing)Revision controlDirect numerical simulationInformationScattering parametersFlow separationNumberTransport Layer SecurityError messageEncryptionCommunications protocolConnected spaceStudent's t-test40 (number)Different (Kate Ryan album)Arrow of timeBitGeneric programmingParameter (computer programming)SubsetWeb 2.0Computer animation
17:23
Transport Layer SecuritySuite (music)EncryptionRevision controlParameter (computer programming)CurveContinuum hypothesisServer (computing)RSA (algorithm)Software testingEncryptionLine (geometry)Error messageServer (computing)Connected spaceNumberMultiplication signWeb 2.0Transport Layer SecurityInformation securityRevision controlSuite (music)Flow separationDifferent (Kate Ryan album)Combinational logicParameter (computer programming)SoftwareWebsiteService (economics)Row (database)Computer animation
18:49
Different (Kate Ryan album)EncryptionSuite (music)Server (computing)Selectivity (electronic)Electronic mailing listCommunications protocolVulnerability (computing)Public key certificateWeb 2.0Revision controlAndroid (robot)Software testingBitWindowPattern languageArc (geometry)Web browserXML
19:27
Suite (music)EncryptionCryptographyKey (cryptography)Transport Layer SecurityBitSuite (music)EncryptionCryptographyKey (cryptography)Formal verificationPublic-key cryptographyElectronic signatureComputer animation
20:01
Key (cryptography)EncryptionRSA (algorithm)FingerprintHash functionPublic-key cryptographyCryptographyAlgorithmEncryption1 (number)Arithmetic meanMeta elementMereologyComputer animation
20:59
EncryptionRSA (algorithm)Advanced Encryption StandardData Encryption StandardMessage passingElectronic signatureDecision support systemHash functionFunction (mathematics)MiniDiscCommunications protocolInfinityEllipseBlock (periodic table)CryptographyBuildingSymmetric matrixTransport Layer SecuritySuite (music)Module (mathematics)AuthenticationSurfaceSoftware developerRule of inferencePublic key certificateMappingBitDifferent (Kate Ryan album)Lipschitz-StetigkeitKey (cryptography)AlgorithmVideo gameHash functionMathematicsElliptic curveEncryptionSign (mathematics)CountingSinc functionFlow separationSuite (music)BefehlsprozessorLine (geometry)Operator (mathematics)CurveCycle (graph theory)Multiplication signAsynchronous Transfer ModeConnected spaceBlock (periodic table)Information1 (number)DecimalData Encryption StandardStandard deviationRevision controlMedical imagingInternetworkingVideoconferencingParameter (computer programming)Graph coloringServer (computing)Communications protocolMixed realityElectronic mailing listPattern languageCodeStudent's t-testCryptographyFingerprintAdditionLevel (video gaming)NeuroinformatikPublic-key cryptographyComputer animation
25:50
Transport Layer SecurityMereologySuite (music)RSA (algorithm)Direct numerical simulationServer (computing)Revision controlRandom numberFluidMessage passingMixed realityMereologyClient (computing)CodeInformationKey (cryptography)Shared memoryPublic key certificateServer (computing)MiniDiscSpacetimePublic-key cryptographyEncryptionHard disk driveDistanceCycle (graph theory)SchlüsselverteilungVariety (linguistics)TelecommunicationComputer animation
27:14
Random numberRevision controlClient (computing)Server (computing)Suite (music)Transport Layer SecurityMessage passingChainEncryptionRSA (algorithm)Connected spaceRootExtension (kinesiology)SoftwareContinuum hypothesisThermal expansionCommunications protocolIdentity managementCodeFormal verificationServer (computing)InformationSchlüsselverteilungElectronic signatureGraphical user interfaceComputer programmingPublic-key cryptographyPattern languageInterface (computing)Core dumpClient (computing)Public key certificateTelecommunicationBookmark (World Wide Web)Operator (mathematics)MultiplicationKey (cryptography)CurveMoment (mathematics)Parameter (computer programming)AdditionMessage passingRootNeuroinformatikElliptic curveConnected spaceRule of inferenceSoftwareEncryptionComputer fileEllipseRow (database)Transport Layer SecurityBitFirmwareComputer animation
30:49
Binary fileFinite element methodEmailExtension (kinesiology)NumberEncryptionValidity (statistics)InformationExponentiationElectronic signatureServer (computing)Transport Layer SecurityClient (computing)AuthenticationRootType theoryCodeConstraint (mathematics)ChainConnected spaceSoftwareKey (cryptography)Server (computing)Public-key cryptographyFormal verificationStandard deviationProcess (computing)FrequencyCASE <Informatik>Revision controlComputer hardwareChainInformationField (computer science)Extension (kinesiology)Block (periodic table)Metropolitan area networkWeb browserCodeMultiplication signWebsiteNumberRoutingOperating systemEncryptionPresentation of a groupSerial portSlide ruleRootSchlüsselverteilungElectronic signatureElectronic mailing listKey (cryptography)1 (number)BitCommunications protocolSampling (statistics)Virtual machineFood energyIdentifiabilityException handlingInformation securityWeb 2.0Sign (mathematics)Computer configurationValidity (statistics)Representation (politics)Term (mathematics)Open setForm (programming)Personal identification numberFunction (mathematics)Abstract Syntax Notation OneAdditionGreen's functionDifferent (Kate Ryan album)Type theoryPublic key certificateMiniDiscComputer animationOperator (mathematics)Computer animation
37:14
Formal verificationError messageRSA (algorithm)EncryptionCodeTransport Layer SecurityCommunications protocolExtension (kinesiology)Electronic signatureChainLocal ringRootComputer fileError messageInformationCodeService (economics)RootClient (computing)Web browserChainServer (computing)Right angleLocal ringCASE <Informatik>Supercomputer1 (number)Software testingTransport Layer SecurityData storage deviceCodeOpen setSign (mathematics)MereologyComputer animation
40:57
RootDirectory servicePhysical systemPerformance appraisalTransport Layer SecurityCryptographyRootComputer animationWindowEndliche ModelltheorieRevision controlIntegrated development environmentVirtual machineHypercubeData storage deviceVariable (mathematics)Installation artHand fanError messageInterior (topology)Electronic mailing listTransport Layer SecurityComputer fileHexagonUniform resource locatorInsertion lossFunctional (mathematics)Set (mathematics)Patch (Unix)Computer animation
42:46
Formal verificationExtension (kinesiology)Direct numerical simulationStorage area networkTime domainCodeInformation securityFormal verificationMatching (graph theory)Right angleFlow separationExterior algebraCuboidLipschitz-StetigkeitSoftware bugExtension (kinesiology)CompilerComputer animation
43:27
Function (mathematics)Transport Layer SecurityInformation securityStatisticsServer (computing)Direct numerical simulationFormal verificationModemServer (computing)Price indexTransport Layer SecurityRight angleMultiplication signComputer animation
Transcript: English(auto-generated)
00:04
So this talk is pretty tightly packed, so I have to run through some of the slides. I may have some time for question and answer at the end, but I'm not sure yet. So let's go. Storyline. Well, I think that doesn't work.
00:21
Hey, so it is maybe you're an engineer, you're just on vacation, or like here, that's the venue of PyCon Russia I've been in the last couple of days, enjoying your day at a pool, relaxing, maybe having a cocktail, super great, yeah, fantastic, final vacation, and then your pager goes off, you see, oh no, SSL error.
00:44
You run to your room, already annoyed, check the logs, and you see something like that, totally gibberish, wow, what's going on here? So I will give you a bit of pointers what may go wrong, and on the line also explain how TLS-SSL works on a high level, including the handshake and certificates.
01:04
So my name is Christian Heimes, I'm from Hamburg, Germany, I've been working with Linux and Python for a very long time, I'm also a core developer working on the security team maintainer of the SSL model at Red Hat, my professional life, where I actually make learning, I work also in security engineering on identity management stack, single
01:24
sign-on solutions called free IPA and related. So this talk, I'll first give you a short history of SSL, a very high level view, a quick way how the connection works, including short intermezzo, crypto 101, after we have
01:41
the handshake done, I'll explain certificates a bit, how the root CAs work, hosting verification, now at the end I'll give you some pointers like resources, links to books and tools you can use, and hopefully maybe some questions. But before we start, should you actually deploy and use TLS?
02:03
There's one very short answer to that, it's yes. The bit longer answer is yes, you should. Because TLS has just one big issue, it's actually not performance, but it's just not used widely enough yet.
02:21
So there's a website, if you consider performance, is TLS fast yet? Explain to you why TLS is actually fast enough, usually it's sometimes faster. Troy Hunt made this nice graph, so it's downloading a big website with lots of resources over HTTP, takes almost six seconds, if you do that in a modern browser with HTTP 2,
02:44
it looks like that, bam, done, one or two seconds, much, much, much faster. Another reason is if you happen to update Chrome today, wow, very lucky, you will see that. Starting like yesterday night or today's morning, depending when you update, any kind
03:03
of non HTTPS link will give you a very big red warning box, not secure. Several websites including Google also give you much better page ranking when you use HTTPS, so there's lots of reasons. And these days it's very easy to get a certificate for no money, use Let's Encrypt.
03:24
Fantastic tool. So history. SSL is sometimes a bit confusing because you have like SSL, you have TLS, and actually one is greater than three, it's the first thing that people confuse when I talk to them about SSL and TLS, that one is bigger than three, and one of the two is actually
03:44
hex 303, yeah. SSL, TLS, sometimes start TLS, I won't get into that, it's actually not that complicated. But yeah, the history. Back in the old ages, Netscape, 1993, 1994, they wanted to start e-commerce,
04:02
sending like credit card information on the internet, and they figured out some way to encrypt that data, so they came up with SSL 1.0, which was never released. Bit later, they came up with 2.0, 1995, the first protocol that allowed encryption on the internet as a standard, and back then Netscape navigator, which was not that
04:24
good, so they figured out, oh, now we have to redesign the whole protocol to make SSL version 3, but at the same time, the ITF, a standardization body, had also wanted to make that an official standard that works across multiple platforms and browsers,
04:42
so they came up with the idea, let's standardize that, but let's give it a different name, and restart the version numbers. It's only a very minor improvement a couple years later, but they came up with a new name, and actually TLS 1.0 is SSL 3.1 internally.
05:02
A couple of years later, TLS 1.1, which mitigated some attacks, 1.2 was a big step. Ten years ago, they added AAD and a better PRF, so the way how certain encryption works is now much better than TLS 1.2 than the older ones,
05:23
and eventually, soonish, hopefully for four years now in standardization, is TLS 1.3, which hopefully comes out in a couple of months from now. The standard is, I think, finalized now, but they still had, like, last two years travel with certain hardware boxes.
05:41
There's several TLS-SSL libraries you may encounter. For us, it's mostly important, the OpenSSL library. The other libraries are used like in Windows and Apple products, but PySME will mostly interact with OpenSSL through either the standard library model or PyOpenSSL. Yeah, these are the most important libraries.
06:02
There's also written by Corey Benfield, secure transport for your three requests on Mac OS to use the Apple database internally. And just a quick look how it looks when you actually create a connection, and as a model, you first need to create some configuration space
06:24
that holds information, which kind of protocols you want to do, the context. You can do it that way or you can do it manually. The first way is the preferred way. It gives you always a nicely secured configuration. We will also update that in case
06:40
there's some kind of attacks. And then you have to create first a connection, later wrap the connection and actually do the handshake, and then you can start to send data over the wire. And now I will run you through what happens at the different stages here throughout the whole rest of the presentation. So high-level view, what happens
07:03
if you do a connection? So how does a protocol work? The first thing that most people will see if you connect, you get this nice, shiny green lock symbol. It means connection is secure. And people think often that TLS SSL is mostly about encryption, but actually it's much more
07:24
than encryption. There's a very long definition by Wikipedia. I've added some of the key words. It's communication security, privacy, and also data integrity. So TLS SSL will not give you encryption but also integrity of the data so nobody can modify and tamper with the information
07:45
and also give you strong authentication of the peer. So the core features of TLS SSL are encryption, which most people figure probably out. It's also interesting to know that protocol
08:00
agnostic, you can run much more than just HTTP. You can run like email, you can IMAP, you can run your database connection over TLS SSL. And sometimes you use instead of TLS SSL something called start TLS that just means you first create the connection, do some communication, then upgrade your connection to an encrypted one. So that's start TLS.
08:22
You also get the integrity check so that nobody can change your data. You get something called replay attack protection. And I can't record your bank transaction and send that a couple of times again later on to the bank to get more money from you. It's also protected. Strong authentication of the server, that's the one thing you get with the certificates and there's
08:44
also a shiny green bar. And for enterprise users, if you like smart card authentication or server to server authentication or for application backends, you can also use client certificates on the client side. So the client can authenticate via the same kind of certificate
09:01
as server certificate. And it's extensible which came very in handy for TLS 1.3 because it builds a partly new protocol on the actual old protocol. We got a lot of different standards, just a couple of buzzwords you will see throughout the next slides. And all this
09:25
combination of different protocols and standards and network layers makes it rather hard to debug and understand what's going wrong. So it can go wrong on multiple layers, starting from the network, crypto can go wrong, the certificates can go wrong, ASM1 is a rather complicated
09:42
standard that the format certificates are encoded in. And yeah, it's a bit of pain, but hopefully I was able to explain some of the issues I see both in daily life of the maintainer SL model and at my work and help you to understand. So first of all, connection. First thing we do
10:06
have to talk to the server is connect to the server somehow. And during that connection, the initial handshake, we do three vital steps. First we have to agree on some kind of parameters to like which protocol version we talk, which cipher suits we talk,
10:22
and we have to authenticate the server so nobody can do a man-in-the-middle attack, so there's no attacker that can just pretend to be like your bank or your email provider. And the last thing we need to do the actual encryption later on is agree on something called the pre-master secret. That's a shared secret that's then used to derive more secrets to
10:45
encryption and protection on the wire. So first thing, we have to look up the name, do a TCP handshake to establish a connection, then the client sends some kind of hello, the server answers with another hello, and some other fields I will fill in later on.
11:06
And finally, then the client sends something back, they do a bit of a handshake, so you see it's ping-pong, ping-pong, and only at the very end we start the actual encrypted communication. That's to make TLS a bit slow if you use it that way. It's also optimized in TLS 103,
11:27
or if you use session resumption, which is a bit advanced topic, I can't talk during my talk. So first step, just establishing this initial TCP handshake, looking up the name, and sending the initial client hello, that can go wrong multiple ways already.
11:46
So just get like a name of service unknown error, usually means your host name is unknown, so maybe some kind of DNS issues made a typo. There's also connection refused, maybe the server is down, maybe the network is down, so that happens on the TCP level.
12:04
Sometimes you get the error message wrong version number, I'll come back to that later. Sometimes just you send something to the server and it just kills the connection, error number zero, which is rather annoying, or in some cases it just blocks, hangs, and does
12:22
nothing. It can be a whole different list of issues, from firewall issues to network connectivity to some servers, even if you send something they don't understand, like new protocol version, they just block, they aren't playing nice. To get the hang of it, to see what's going on,
12:42
and to diagnose the first kind of issues, I always start to first look up the host name, connect to resolve it, maybe send a ping to the server, so ping just sends a ICMP package to the other peer, it replies, protocol comes from submarines, so the ping, and hopefully
13:01
the server replies from there. It also helps to see the basic network connection works. You can trace routing that pings the different steps, so the routers and servers, the requests are routed through, that might help. And if nothing else works, you can still use a tool called TCP dump to look on the raw network layer,
13:23
which is kind of a lot of gibberish and hard to read, I can't read that myself very well, but there's other tools I'll show you later that is very, makes it much more approachable. So, one tool you can use to diagnose the kind of issues when you run on a server,
13:46
that I discovered just like a year ago, is, who has heard of the tool cURL? The download tool? It's just a common tool to download resources, also has two options,
14:02
dash S, dash V, which gives you an enormous amount of information about the handshake, you see all the steps in the handshake on the console. So, these tools, just to summarize them up, DNS look up, ping, wire shark, cURL wget, there's also nmap, port scanner you can figure
14:22
out which ports are open or the firewalls blocked, or very, if you have access to the server, just read the firewall logs, read the server logs if you see any kind of errors, or if you have an HTTP server, well, just use your browser, just try to connect to your
14:42
web browser and see if that works. Okay, we have the TCP connection onto the server, we send the initial hello, and let's see how the handshake works internally. So, again, we have the DNS lookup, we send the client hello, the client hello, this package we send as a first, tells the server which kind of versions we can talk,
15:04
which ciphers we could support, and some random value. And the server, when it can handle the information, sends back the server hello, and it sends back the information which ciphers you selected, which version is selected,
15:22
and also random value. And from there on, we go on. And we had that a couple minutes ago, so either wrong version number connection hangs, if the server doesn't reply with a server hello,
15:42
or replies with this information wrong version number, that often means you may not actually talk to something that's an SSL or TLS server. Maybe you have misconfigured your Apache or an Nginx web server to not actually respond to HTTPS. It's something that is rather common if you start to deploy a new server, and something that's not very obvious.
16:05
Several other error messages you may get from OpenSSL fail to negotiate acceptable TLS parameters, handshake failure. That can mean that any kind of this information, what you support as a client, is not understandable by the server, and there's
16:21
some kind of policy the server tells you, I don't like to talk to you with these parameters. There's no way to get more information directly from the handshake, because the server just sends this generic error message back, which is a bit of a pickle, but there are other ways to get more information. Another unsupported protocol that may mean that the server doesn't understand
16:45
the TLS protocol, but sometimes when it doesn't understand the TLS protocol, version also sends the first error message. Again, it doesn't know what you're doing, maybe it just kills you, kills the connection, and if you use a newer version of Python, do you have different kinds
17:03
of protocols on the client side? Maybe you selected the wrong one. So, handshake failure. It's internally error number 40, means, for example, you can't agree on a common cipher suit. The list of ciphers you can speak happens rather often if you update OpenSSL to a new
17:24
version, or install a security update, it disables old cipher suits. Unsupported, that can also mean sometimes, a couple minutes ago, a minute ago, that the server doesn't know the TLS version, or that several of the other parameters you send to the server is unknown,
17:41
not understandable. So, you got this error number 40, and a whole bunch of possible ways it can go wrong, and the only way to figure out what goes wrong here, if you get that error, is actually use a tool that just tries different combination of parameters over and over again
18:01
to give you a hint which kind of cipher suits and TLS versions your server supports. One is a common line tool called SSL scan. So, every line you see here, like this reject, fail, any time you get this line, it means it creates a new network connection, configures just one version of TLS, SSL, one cipher suit, and then gives you the kind of
18:25
error message. So, and that usually creates like a couple of hundred connections which looks a lot of ugly on the website, on the web server logs, but it's the only way to figure out what's going on. Or, if you can have a public service, I totally like this website,
18:42
it's SSL labs, so make small screen recording, it gives you very nice diagnostics, and so here tested Python.org gives you some grading, tells me how the certificate chain looks like, which protocol version I support, and it even gives me not only a list of all
19:01
the cipher suits, but also different version of Android, Windows, Mac OS, different browsers, and tells me what they were able to negotiate as best selection of cipher suits. Also, it tests for several known attacks and gives you a list and which kind of vulnerabilities
19:21
your web server has, or which countermeasures you have to take. Okay, we talked a bit about the cipher suits. I'll give you a very, very short introduction, like three minutes in crypto to give you some of the steps we have in cipher suits to explain
19:41
how the cipher suits actually build up. And you also need that later on to understand how certificates work, because both for the handshake verification of certificates and the chaining, the signature of certificates, we need public key crypto. It's a small, very nice IKEA way to explain it. So public key crypto means you have two different parts,
20:04
a public key, something you can just hand out to everybody, and you have a private key. That's why it's also called asymmetric crypto. There are basically three ways to do asymmetric crypto. There are two ways. One way is you can use your private key to sign a
20:22
document, or actually the fingerprint, the hash of a document, and people with a public key are able to verify that you have signed the document, not some attacker. That's on your right side. Or on the left side is if somebody can use your public key to encrypt some data,
20:44
and only the owner of the private key is able to reverse that encryption, decrypt the actual encrypted data. So asymmetric encryption, there are a couple of algorithms. The red ones are the bad ones you shouldn't use. There are also, yeah. The thing about asymmetric encryption is
21:07
it's extremely slow. It's a very complex, very lengthy, mathematical operation that only can handle a couple of bytes, or it takes lots of CPR cycles. If you download large images, videos, the Internet, computer games, you don't want to spend that amount of CPU time,
21:25
so we need another way to encrypt all the information. That's called bulk encryption. You've probably heard of them. So these days we use either AES or ChaCha20. Again, the RC4, triple DES, or the DES one are the old ones. And these typically take like a couple of CPU
21:43
cycles per byte, or even CPUs these days, like if you have a modern Intel AMD or ship, you have dedicated CPU instructions to make AES even faster. So we also need to sign documents
22:01
or sign certificates. You can use RAS for that, or there are several kind of new elliptic curve algorithms. Elliptic curves operate with different kind of math. This is usually faster to operate and make smaller keys, but are secure too. One very important thing, since signing is also very slow, you have to first hash your document, make like a fingerprint,
22:25
and then you can sign the hash. The hash is very small, usually like 16 bytes or so, and you can hash like very lengthy documents and then sign this very small hash. And there are also several hashing algorithms. MD5 and SHA-1 are very insecure, don't use them
22:46
these days. Mostly if you have TLS or certificates, it's SHA-2. And the third way to do asymmetric crypto is something called a key agreement protocol, or a so-called Diffie-Hellman
23:02
operation, where you can use some tricks to agree on a common secret without sending the secret over the wire with this kind of operation. So Wikipedia explains that it was mixing colors. You have your private color, you have a common public color, you mix your private color with
23:23
a common color, send it over the wire. The other side adds its own private color to the mix, and they both have the same color at the end. And all these bits and pieces build up this so-called cipher suit. So you have the key agreement to agree on a common pre-master secret,
23:44
you have something to authenticate the peer, you have the fast block encryption, which also sometimes needs a motive operation for block ciphers, and finally the hash functions you use to verify some of the parameters. And that's the cipher suits. So you can still just go
24:04
through the first line to keep in time. The first one is an elliptic curve Diffie-Hellman agreement, use also elliptic curves to authenticate the server, AS with Galois counter mode as block cipher, and SHA-384 to verify the connection. That's the official standardized
24:23
name from the IANA, but if you ever used OpenSSL or configured cipher suits in Python, they look totally different because, well, OpenSSL decided why use standard names, let's count with our own rules and old names. They map rather funny, so the cipher suit maps
24:45
to that very short name because they figured out they can just omit lots of bits and pieces for common things. Some map to slightly longer names, you can actually recognize the different bits and pieces. You can use the new version of Python, you think Python 3.6, you can use
25:04
the getcipher tool to configure a cipher suit and then get a list of supported ones. If you work with some kind of governmental bodies, you may also run additional restrictions with cipher suits called either FIPS, GUST, or the Chinese one. These are standards
25:26
you should not actually use unless you have to work either for the US government or for the Russian government or the Chinese government or have like restrictions on the market you sell. So a typical Python developer or engineers ignore these, especially don't
25:44
look into FIPS mode, FIPS mode is a mode to run OpenSSL, you don't need that. So TLS handshake part two, just to wrap up what we have learned so far and add that to the mix. So we sent the client hello, the server sent back, the server hello also sends back
26:05
the certificate chain which will be the next part of my presentation and in the RSA handshake, the old one we used, the client would just select a secret encrypted with the public keyed code from the server as part of the certificate chain and then send it over to
26:24
the server, the server can then use its private key to decrypt the pre-master's secret and finally they change cipher spec that means they switch over to encrypted communication. This variant had one very big issue, since a client selects the private, the shared master
26:43
key and is sent with a wire, if an attacker with lots of hard disks would just record all this information like for years and years and years and then somehow get the private key, attacker would be able to decrypt all traffic for the last decade or even longer and there
27:02
are some entities who have big, big disk space somewhere in the desert of wherever. So that's why we these days use a different way, we use a Diffie-Hellman key exchange, that means the server sends back some parameters and sends back his public key to the client
27:24
and uses his private key of the certificate chain to sign that and the client can then verify this signature with the public key and it also generates on Diffie-Hellman private public key pair, sends the public key as the final message and both have then agreed on a
27:44
private key. So that's the firmware Diffie-Hellman key exchange with the very important step, it's perfect forward secrecy, so it's since they throw away the keys of each operation, these handshake, I think I can't recall that. Although actually in TLS 102 it's not yet secure,
28:06
there are actually ways to crack that with session resumption but that's fixed in TLS 103, that we'll talk for next year. In Python you can't get that many information so I'll now use the OpenSL command line tool to make a connection with the cipher suite, the modern one
28:29
and that's the certificate chain you'll get, I'll come through that in a minute. Some other information you will get, you see which kind of connection it made and just it's a bit hard
28:41
to read, you don't understand what's going on on the wire but there's one tool you can look on the wire what's going on, it's called a wire shock and I'll show you how cool a tool is, another recording. I made a rule to look for 443 HTTPS Python, made a connection with that command line tool, we're now filtering out, just interested in the TLS communication,
29:06
we created a connection TLS 102, the wire from TLS 102 but that's not very important, we sent also the host name we're interested to talk to and the server replies with the server hello, we selected the cipher suite, we selected some other parameters, elliptic curve,
29:29
we got a certificate chain back, so this is a certificate we got, they sent two back, the end entities are intermediate search with lots of additional information,
29:43
we also now have the key exchange, so you see if the Diffie-Hellman key exchange, elliptic curve Diffie-Hellman, that's a public key, there's the signature with the private key of the server and then the client verified the information, also the client key exchange sent
30:03
its public key and at that moment we switched to encrypted communication and that's the handshake and this is one of my favorite tools to look into communication, but you need a GUI program for graphic user interface which makes it not suitable for servers
30:21
but in the beginning I talked about TCP dump, you can use TCP dump to dump network communication your server to a file as a root user, download that file to your desktop computer and use the tool to diagnose that, okay you have like 12 minutes left,
30:41
it's enough for certificates, so we have the handshake, we have the pre-master secret agreed, now we need some way to verify that we talked to the right server, not to some kind of attacker middle-to-middle attack and the whole verification process is done with something called
31:00
certificates or public keys for such a PKI, the standard behind PKI is the other very old standard from the 80s, it's called X549 certificates, X549 are encoded in a also old standard called ASN1 with different representation,
31:21
most of you have seen, if you have looked at a certificate or private key, something it looks like base64 encoded data was the begin and head up lock, that's just actually base64 encoded raw ASN1 and these certificate always come in a pair of certificates and private keys,
31:44
one way to look at certificates, oh there's also additional information, I'll run through in a minute, to look at a certificate there's a tool for text-based consoles and OpenSL 2, so OpenSL X509, we use the dash text option, you get the whole
32:03
human readable text, we use no out, then you don't get the certificate again, so it's a bit confusing but yeah, and you get information like that, certificates, so you get some data, first of all they have a version number, these days you will only see version 3 ones except
32:24
if you create your own ones without certain extensions, they have a serial number, that's a randomly selected number, they used to be in serial but there were attacks and with random selected serial numbers it's a bit more secure for the CA, certificates are always signed
32:43
by somebody, so if you sign a name in there, they're valid for a certain period, with Let's Encrypt you typically have I think three months, yeah give or take three months, and these also the subject that's the name of the entity that requested the certificate,
33:02
that's the certificate for the EuroPython website which actually has not the common name, so CN stands for common name, EP 2018, well it's later embedded in the certificate, and finally we have the public key with some additional information, that first block I showed you, that's actually the version 1 information,
33:24
we have additional extensions, the x59 version 3 extension, then the version 3 certificates, which all certificates these days have, they have like a key usage, how to use the certificate, the signature means you can use the Diffie Hellman key exchange and sign the secret,
33:46
key encipherment means somebody can use the certificate to encrypt the key, so this certificate you can use both kinds of encryption and signing, without these you wouldn't be allowed to sign, other fields you can have in there is like signing CA's, signing revocation lists etc,
34:05
you also have an extended key usage which typically is web server, some for the web client, you can also have extended key usage for signing code, CA falls, so that one is not a CA certificate, it's an entity certificate, identifiers to build up the chain, and some ways to get the
34:31
certificate, OCSP is online certificate revocation protocol, status protocol, and finally a list of names the certificate is valid for,
34:42
and at the end that one is signed by a CA, that's the signature, so we have three different major types you see in web browsers, you have first of all the trust anchors, also called root CA's, these are self-signed certificate, they can pre-install
35:03
with a web browser or with your operating system, and these are fully trusted certificates, so then you have intermediate CA's, these are also CA's that are already signed by another one, you can have one, two or just a chain of them, we use intermediate CA's to keep the root CA's
35:24
locked away securely, so the intermediate CA's are typically in special hardware devices, and the root CA's, the keys printed out on paper and stored in a vault securely and not even on a hard disk for security reasons, and finally the server certificate or the
35:44
more technical terms and entity certificates, these form a chain, so the root CA signed the immediate one, the next one signed the next one, and finally the entity certificate, the one you have on your machine, and you have to post the website to send the whole chain
36:03
back, so I just skipped through that, there's a different field you can have, going to be a bit more too much time to explain that, so the chain, as you can see here,
36:20
another output tool from other conference, I presented the slides at, you first have the your end entity certificate for your website, then you have the next intermediate one, and the root one will stay so on your browser installed, and just in case,
36:42
just in case you wonder, sometimes you see this big green bar, that's called a standard validation certificate, this is just some additional fields on the certificate, they use an extra process to validate you, but these are not special certificates, other than they have this additional field, and one thing I want to point out,
37:03
please keep your private keys secured, and don't throw them like in the bin, so one of the most common things that can go wrong with verification is you get that kind of message, the most annoying one, and too bad if you still use Python 3.6 or Python 2.7,
37:26
you won't get any more information back from Python, 3.7 is improved, I added some extra code, but you just get something went wrong, so you have to use an external tool called from OpenSSL, for example, to diagnose that, so it's S client, you connect to the S client,
37:46
so he used bad SSL, which is a nice collection of errorless certificates or something is wrong, and for that case, I also have to send the host name I want to connect to,
38:00
and I get error messages back, for example, here certificate has expired, and I'm going through several of the error messages you make, come back and give you some hints what can go wrong, so one thing is obviously, so it has expired, so you have to get a new certificate somehow, sometimes more rarely you get
38:24
something like it's not valid yet, that often means that your clock is wrong, so if you have Raspberry Pi, you don't have clocks on the ship, on the die, you have to use an external clock, so if something goes wrong, then you get that error message, if you generate your own ones,
38:45
you may get some kind of very funky error message with handshake failure, these don't happen if you get official certificates. On the client side, if you connect to a server and have some kind of issues with the actual
39:01
chain, there can be multiple issues you can have, the one if you run test certificates, and you get self-signed certificate as error message, then you have enabled SSL verification, but didn't add the certificate to your trust store, or had some issue with your test certificate.
39:23
Unable to verify the first certificate in the chain, is in almost all cases I've witnessed that the issue that the server doesn't send you back the whole chain, only the end entity certificate, so it's slightly misconfigured, browsers can work around that, you can use information from the certificate to look up
39:44
the chain and build that on their own, it's called AA chasing, tools like Python, any kind of command line tools don't do that, so you have to fix your server. Unable to get local issue certificate is a sign that you don't have the root CA loaded,
40:05
perhaps it's not installed, perhaps you're missing the way you get the root certificate, so you have to load them somehow, and there are multiple places where the certificate can be stored, or sometimes you get the also self-signed error message, which is often a sign that the
40:25
server sent all to the root CA back, but you don't trust the root CA, so the server can optionally send as part of the chain also root CA, but if you don't trust it, then it looks like this self-signed error again, and if you update your Python 3.7, well you get actually
40:42
a much better error message, actually get the same information you would see in OpenSSL, so here for example unable to get local issue certificate, you're welcome, I was annoyed too, I was very annoyed, and it wasn't that hard to add that, I wanted to figure out how to do that,
41:00
so root CA's, root CA's can be stored in different places depending on operating system, or be not available at all, so Linux or BSD is typically some file that's compiled into OpenSSL, so if you compile your own OpenSSL, it may not work, requests also have the certify package, which just packages certificates which get rid of the error, but have other issues, on Windows
41:26
added a hack to add certificates from the Windows third store, which does not work properly if you have a newly installed machine, I didn't know that before, I want to edit that, and on MacOS you currently have to install certify if you use the official installers, because
41:45
internally Apple uses a patch OpenSSL, we can't use that trick with Python installers, on Linux they may be, so vendors have never agreed on a specific location, so you can
42:01
have a long list of places you can look, we don't have that list in the SSL model in Python, but you can use this small tool, small helper functions to get a list, also ways to override that, so it can set environment variables,
42:22
so I mentioned that I'm not a big fan of certify because you have to keep your certify package updated, if you don't do that you may run into some issues I found in New Relic a while ago, they had a very ancient version of certify and requests with very outdated invalid certificates,
42:46
so just the final one, hosting verification, because I have just one minute left, so we also have to verify the host name match with the certificate that uses this subject alternative name extension, and I had multiple issues to get that right in Python,
43:05
the engineer, there's so many ways this thing could go wrong, we had like six major bugs, several CVE, six CVEs, several major bugs, and now we use OpenSSL for that, so that's a new feature, also libRSL added that until, yeah,
43:25
yeah, I found a bug, libRSL worked on Python 3.7, and that's if you actually paid for some fancy medicine for my then sick cat, so thank you libRSL, you paid the vet, and final remark is if you do HTTP you have to be sure that you use the same host name
43:46
for both the server name indicator and the actual GET request, so TLS 103, out of time, yeah, out of time, so skip that, summary, so some of the tools you
44:01
can use, and I highly recommend to get one of these books, especially the Bulletproof TLS SSL, and I'm right on time.