 I just want to present to you, we need a new person just because you know who he is and I'm trying to take my life but for the rest we will continue on the user channel. It's my work. Yeah. No, no, no, no, no, if you are sending. So everyone and welcome to my talk. I am a senior software engineer who is maintaining the open SSL package for Reddit and price Linux and Fedora. So that makes me at least a little bit qualified to talk about this subject. So this is my agenda. So why we will be talking about the API changes in the new open SSL version. And so we start by the API changes. Why should we port to the new API and then we go through the actual changes and what what they mean for us. And also we at least a little bit talk about how to keep the backwards compatibility with the old API viewport. So why the API changes. The old API was extremely prone to API breaks. That means the reason is that it was actually prone to API breaks not only between versions but also depending on build time options. Here is the example. The problem is that the structure is public and there are parts of the structure which are conditional on build time options. And that really means that you don't have any single API. Various distributions can choose different build time options and then they are not compatible. So why do the changes because we need to bring better API stability in future without limiting internal changes. And so the new API in the new API the structures are opaque so the members are hidden. And this also brings like improved support for external crypto devices and tokens because the applications that use the API cannot have or cannot depend on the actual data inside the structures. And so the external devices can choose different implementations or things like that. So why should we port. Of course the main reason is that we should port if we want to access any new features from OpenSSL from any future versions. Because the old 1.0 branch is now only for bug fixing and there will be no features added. And there is no plan for any future release on this old API. For example the OpenSSL 1.1 X that means not 1.1.0 but 1.1.1 or what will be the name I don't know. So the next feature release should bring TLS 1.3 support. And I thought it's cool. Well not so much because it's a little bit tedious work but the support for 1.0.2 will also end by 2019 and then there will be even no bug fixes there. And one of the reasons I will like you if you port. So let's port. The first difference is in initialization before you need to call OpenSSL at all algorithms or SSL library in it. These functions you call one of these based on whether you want to use TLS stack or not. Now this is not needed except when you want to load configuration file which is actually useful because in the configuration file you can configure engines and other things. And also you need to explicitly initialize if you have some special requirements. These are mostly about low profile if you actually don't want to initialize something. This is example how you initialize if you want to load the configuration file. So the first one is equivalent to the OpenSSL at all algorithms and the second one is OpenSSL library with loading the configuration before you had to explicitly call out configuration. And the call is a little bit different now. There is also no need anymore to initialize log and threaded callbacks, thread ID callbacks because OpenSSL now by default uses the system native locking which for Linux is retards. Also clean up. Before there were multiple calls depending on what you called for example whether you loaded error strings and initialized EVP sub stack of the API. Now it's not needed because it's done automatically on exit handler. You can explicitly call it. You use OpenSSL cleanup function but you should never do that in library because the cleanup call will make the OpenSSL library unusable. There are some hacks in the library so you don't actually need to call the cleanup because if you load it for example by DL Open then it will take care of it and it won't unload. So it should not cause any leakage of data. So the hash is API. There is actually the old API or very old API is to use directly the actual algorithms. This is actually deprecated or it should not be used anymore for a longer time. It's not new in 1.1 but I have to extend it. You should use this general functions which is EVP interface and before you in 1.0 you used EVP MDCTX init and destroy or you could directly allocate the structure. Now you need to use of course because the structure is opaque. Now you have to use the new and free calls to allocate the handle pointer to the object. There is an unresolved problem and the serialization of intermediate hash state. This is usually not needed but there might be some special applications where you need this. This is being worked on for HMAX before you also directly allocated the HMAX structure. It's not possible anymore. There was actually no new and free or equivalent calls before so now you have to use them. Again there is no serialization and if you need to reuse the context you don't want to allocate it and allocate new one. You use HMAX CTX Reset. Here is some example. Of course there is no error checking in this example but basically all the calls now return positive value as a success or one and zero or negative values as error. Should the data be non-terminated and should the data you pass now terminate? No, no, no, no. It's actually no. So whether the data you pass to the update or function, whether it's not terminated, no. It's always the lines. You have to pass the lines. This is not no change from the one OIPI. For symmetric ciphers you again before directly allocated EVP Cypher CTX structure then initialize it by EVP Cypher CTX in it. Now you have to allocate it by the explicit new and free call for the allocation and again there is a reset call for context reuse. Here is the example. So basically you see that the new API is trying to get more regular than before. For public key cryptography the preferred interface is to use the EVP PK functions for the signing, public key encryption, decryption, signature verification. But you still need to work with the RSADS, ADH and EC key structures which are again made opaque. Now when you, for example, generate keys or manipulate the keys somehow, for example, initialize them, load them. There is some naming convention and that the set zero and get zero functions don't increment the reference counter inside these structures. And that means that the ownership is transferred for the set zero functions. If you, for example, set some public key component or private key component of the RSA key, then the ownership of the big num value is transferred to the EVP or the actual key structure. And in case of the get zero functions, you again just obtain the component and you have to, ownership is staying with the key and you don't reallocate it. Because it's a reallocate when the EVP PK or the key structure is reallocated. There is some detail that the public key components of the actual keys need to be set before the private key components. The library checks whether the public key is set when you are setting the private parts. In some cases it can be a problem, then you can work around it by setting zero big nums. Not now, because the now values are actually like unset the part. But this is of course a hack. You should not use the key by passing it to any function that needs the public key components in this case. There are the set one and get one functions which increase the reference count. And in this case you have to free the data that you pass into these functions or get it from them. These functions were already present in 1.0 API. For TLS, there are fairly minimal changes unless you do work things. Of course that means also that the misleading SSL API names are kept. It wouldn't make no sense to rename them because it would be just renaming of too many things. The most confusing name, the SSL V23 method which is like wildcard method for all the protocol versions supported. This was actually renamed because that was like most confusing and there were the most issues with this name. Again initialization without configuration is implicit but better it's to load the configuration files so use the initialization with loading the config. If you do some weird things you need to in some some accessors to the internal SSL data or TLS data that's not there in the API. Please report because missing accessors take care of SBOX and even in the 1.0 release the missing accessors can be added. When you report and you want to keep the compatibility with 1.0 API, the best way is to implement the missing calls in your application. You should try to keep the missing symbols hidden. You can either rename them via macros so the names are not confusing when you reduce source code. You can also use static functions if you for example use these calls only in single source code file. Sometimes of course ifs are inevitable but can be minimized their usage. Here's the example how you compare the SSL version number so for the version that I ordered in 1.1 you implement the functions in your code. So summary, porting is fairly trivial but it can be tedious because there might be multiple calls needed and so on. There are some examples on this URL, there are pitches for the 1.1 transition which are shared between various distributions. API manual pages are improving and upstream is now fairly responsive to documentation fixes and improvements. Thank you for attention and for eventually porting your applications or other applications to the new API. Any questions? You mean the sterilization? Yeah, unfortunately there is no way. I would say that there is a way to export the state of the crypto encryption for example. So this is considered bug but I would say that this won't get in 1.1.0. It might get into the next feature release because that would be a big change because it would require new APIs. How do PECs certificate directly into the application so that SSL doesn't load certificates from this but directly from the... Yeah, this is no change from before. You can basically, for example, there are many ways how to do that but one of them is for example that you have the binary data of the certificate inside some static... ...data and you load it via bio-memory, memory-bio which is initialized by... So you should see those same codepads to get from file... Yeah, you use memory-bio instead of file-bio. I have no idea. So the question was whether the other libraries plan to move to the new API. I have no idea, unfortunately, but I suppose that they won't, at least not in the near future. Maybe after some time when the advantages of the new API is clearly shown that they might. Definitely, there will be new APIs, new features. Yeah, so the question was whether there are any further plans for improvements of the APIs. I actually hope that there won't be any similar kind of API break in the future. Yeah, there can be some minor API breaks but I hope there won't be such a huge break in the future. And there certainly will be new APIs for new things. Like, for example, currently there is some thinking about better generalization of the certificates and private key-loading and things like that. Also including support for TPMs and so TPM keys and so on. So there will be improvements and I hope that they won't be incompatible backwards. The question was about the OpenSSL tool, whether there are changes. So there are some changes in the OpenSSL tool but they are much smaller than the changes in the API. Let's say I'm maintaining some old demon which uses 1.0 API and does it mean I won't be able to use TLS version 1.3 without migrating to the API? Yeah, so the question was whether applications of system demons which are using the 1.0 API, whether they will be able to use TLS 1.3, yeah, they won't be. There is no plan to backport TLS 1.3 support to 1.0. Even I don't think that as a downstream we would do such a patch because it would be basically a re-implementation. The thing is that there are many more changes in the library than the API changes. Especially on the TLS tag there are multiple changes which touch the whole implementation and backport would be basically a completely new implementation. Maybe it would be actually possible to take some backport from library as a cell code. I don't even know whether they follow the upstream OpenSSL changes of the TLS. Unfortunately I think that it's not possible to do it like shared library but you can copy. There are some efforts to create some like copy library which would help with this. You basically would include a source code. But I don't know if there is any definitive. We are full time. So thank you.