 My name is Tomasz Maraz, I work in Red Hat under the crypto team, which focuses on encryption and other cryptographic technologies on the platform, on the rail and Fedora. So I will, what, yeah, okay, for the start I will talk a little bit about history, perspectives it gives us, then I will get to the point, what is the crypto policies, why do we need it, I will show you some demo of the functionality and I will talk about some details and also what crypto policies isn't about and some future, for the history, I won't go through all this stuff that I put on the slides, but basically cryptography was started to be used very early in history, but at the old times these were mostly substitution ciphers and stuff that can be very easily broken, it was broken like the first century, first millennium after 80. There is one thing that's not yet deciphered, it's the Voynich manuscript, but the reason is that the context is unknown and there is too little information about it, and it might not be even a cipher. One interesting thing is that at 1917, the Jobert Wernum invented the wine time pad, which is the only fully mathematically proven unbreakable cipher, but there is but, and that's the context, I won't go into detail, but there are many ifs and so on. This is modern cryptography, for Symetric we have DES, it started with DES, now we have AS, for the public key cryptography it was also invented in the 70s. This is a timeline of secure protocols or the major one, which is SSL and then later TLS, this is when it was published, the standard was published and this is when it was deprecated, and this kind of line shows you when it was insecure, so SSL insecure that we know that it is insecure, so SSL v2 it was like this, so since the beginning, but it was anyway deployed, so yeah it was insecure but deployed, at this time it was not that much deployed. For SSL v3 we are a little bit worse because this is kind of longer but we still have SSL v3 servers, it's not on public internet, but it's not that much anymore anyway, but for the others you can see this is still a complicated situation. The only secure protocols which we can reasonably that are secure, TLS v1.2 and of course TLS 1.3, there are some ifs for TLS 1.2, but I won't go into the detail. So what perspective this gives us, the progress in design of new ciphers goes hand in hand, with progress in crypto analysis and algorithms and protocols will be broken and replaced, that's the fact. We need to get accustomed with it and of course there is a huge pool of legacy things that we need to communicate with and that might not be that secure communication but we need to communicate with them, we cannot like just say no we won't. So what's the crypto policies? It's a set of configuration files or configuration file snippets that are centrally managed on the system, they have multiple pre-designed policy levels which are maintained and they cover core crypto components of the system. There was a presentation in the morning about what are the crypto components but I will also talk about this. They are present, the crypto policies are present on current federal uses and they will be in relay, they are in relay beta. Why do we need it? This is basically coming from the perspectives, cryptography and secure protocols are widespread in the operating system and multiple cryptographic libraries provide the implementation so we have and we have relatively fast changes so we need to like adjust relatively quickly especially if on enterprise products which have a long life cycle and we have multiple things to configure so it would be very hard to require the sysadmin to do all the stuff or configure and so on. And we have legacy devices which use insecure or partly insecure algorithms or protocols and we need to communicate with them. Let's look at some demo and this will work. So let's say I have a Http server which is configured to use only TLS v1 or v11 and I need to communicate it with on relay beta which is not the system here but I have installed policy from relay beta here. Let's say I use normal connection to this system with open SSL and you can see that TLS v1 alert protocol version but that means that the protocol is not accepted by the client and or rather the server says that the protocol that the client offered is not accepted by the server and then I can try TLS v1 and it will work but this is somehow overriding the system configuration and but I can do or I can show you also Firefox. Yeah you can see it's failed. Then if I do I will set the system wide crypto policy to legacy with the update crypto policy set legacy command. Then the open SSL client magically starts working and you can see that it used basically the highest available protocol which is TLS v11 and hopefully the Firefox will work as well. Yeah it loaded the page. So let's switch back to default because you want to be secure or fully secure. Well let's say not that legacy policy doesn't make you insecure but it will make it more or less secure if you are connecting to the legacy side. It doesn't mean that if you connect to side that uses proper versions and algorithms it will make you insecure. You will use the best algorithms that are available. So the details we have these crypto libraries and other applications that are considered to be core. This is open SSL new TLS and SSN Java for the crypto libraries and the other applications which basically are not using the TLS protocol but other protocols but other secure protocols and the Sacher Burrows 5 bind open SSH which has two configurations for client and server separately and for the Burrows one for IPsec and IEC. These are the policies that we provide. The legacy is let's say at least 64 bit security. Default at least 80 bit. Next which is federal only policy but it's actually the default on rel 8 beta. This in addition to the federal default removes TLS 1011 and requires 2k defi helmet RSA keys and it should be for this reason it should be 112 bit security. There is exception and that's shawan because shawan is still used in DNSSEC and we cannot like completely switch it off. So this somehow breaks the rule for 112 bit security for collisions and signatures. It's only 80 bit. Future is the conservative level and there are only 256 bit ciphers and no shawan. FIPS is a special policy that's for use by FIPS mode setup. You shouldn't like set it manually. You can actually but you are on your own if you do this. So summary is use default, use legacy only if you really need it. Use future to test compatibility of your newly created or deployed application. It's not usable for general use but it's useful if you are deploying a new server for example it's a good idea to check if client which uses future can communicate with this new server. Even legacy level doesn't enable everything or make your system insecure. So and we do things like disabling SSLv2 which is completely removed and there is no implementation anymore and SSLv3 is disabled during the build time. So even if you use legacy you unfortunately won't be able to communicate with SSLv3 only server and the reason is that eventual downgrade can be catastrophic and we don't want to actually make the legacy policy to be like really insecure. Custom levels are currently somehow possible but it's very hard to like do them. You would have to basically create a policy, install it on yourself and it would be like if we make some change there is no fixed API for the policies. So yeah it can be that with a new version of cryptocurrencies it will be broken so that's all. These are the files structure on the system not that much interesting. There is something like locady which allows to add some additional configuration to the to the predefined backend configurations. This is actually not that useful for custom cryptocurrencies but it can be used for things like mentioned on the slide. Currently it's used for adding PLM kit proxy to NSS by default. What cryptocurrencies isn't? They won't make your system magically secure of course. You still need to for example handle system updates and so on. There is no support for data at rest. The reason is that the requirements are very much different than for data in transit. It cannot magically configure things it doesn't know about. For example we had this talk about Russian ghost implementation and currently crypto policies don't know about it and yeah it cannot configure for example if you have your application that uses third party crypto library yeah it won't follow the crypto policies. What to your future? We would like to really work on the custom crypto policies which would mean that the policy will be some kind of policy definition file there will be scripts or tools which will deploy the policy they would update it if the backend changed but or the crypto policies package changed but in a compatible way so it will seamlessly work. We would like to cooperate with other Linux OS vendors or distributions so the system by crypto policies are used everywhere and we would like at support for moral gardens of course and we would like to add more back ends which mostly yeah these are the most critical examples like go lang and lib SSH. Maybe sometime in like more distant future we should think about the data at rest support these resources. So what's the summary takeaway? System wide crypto policies help with maintaining your crypto usage up to date help it it doesn't mean that they solve all the problems right they provide some legacy compatibility they provide you a way how to prepare for future and if something doesn't work use this command. Otherwise please use the code. Questions? Okay. Can I ask a policy for primary follow up? What? Policy for software so I'm saying concentrate on this policy? Unfortunately yeah the first question was whether the legacy policy will help me with connecting to really old legacy devices which use for example SSL we do and the second question was whether the policy can apply the system well can apply policy for each binary separately. So the answer to both question is no the first of course and I talk about it that we some some things are completely removed from the system for because they are really insecure from and there is no implementation actually and some things are disabled on build time and legacy policy cannot do anything with that. And for the second question actually the policy or for most of the back ends the applications can override the policy. So they can say that yeah we allow whatever TLS version or something but the default configuration of these of these applications as they are in the in the OS should like respect the policy defaults if you override it manually in the configuration file then you override it. Okay thank you. Yeah the NSS app will go to overwrite a deny so if you deny something it won't overwrite it but you can turn off something that's allowed. Yeah for NSS this is not possible to like enable things by this over specific configuration or that. What other sorts of policies can you set so for example I guess you can set the TLS version and maybe Cypress sweets. Yeah. Can you set so for example if I wanted to say every open SSL application on my system is able to trust, intervene, and search directly without requiring whole searching is that possible? No so the question is what can be configured by the policy currently it allows you to configure the Cypress the key lengths and the protocol versions basically that's it. Yeah do I correctly understand that the algorithm is totally unknown by the policy if they're just rejected? Yeah the question is whether when the policy when the algorithm is unknown to the policy it's rejected yeah the the current configurations as they are basically disabled on algorithm. Okay. The second question is what's the opinion of for example the OpenSSL team about the change in your roles? What does the OpenSSL team thinks about introducing something similar in OpenSSL itself? The question was whether OpenSSL upstream team considers including something by themselves like similar I don't know. You didn't discuss it or what? Well basically I discuss it when I submitted the powerful request that allows loading the or makes the OpenSSL loading the configuration file by default there was some discussions some small discussion but I feel it like for them it's like this is not basically what they have now allows you if you use OpenSSL in isolation it basically allows you to do this configuration so but it's not I don't I don't really... It's not a system like solution? Yeah yeah it's not a system like solution. Yeah? The question is how can they do this implemented? I mean you're writing OpenSSL so you have files based on your policy or just modifying OpenSSL so if my application is not involved in the policy maybe not but you need to use OpenSSL how are you focusing on that? For OpenSSL the configuration file is loaded by the library by default you can I think you can override it so it won't load it. But are your policies generating this? No the update crypto policy tool basically updates the configuration file it's somehow a little bit different but the configuration file loads the policy it includes the configuration file snippet that has the policy configuration and if you disable loading the default configuration file then you won't get this applied. Yeah? The question is I'm not able to get the list of regular policies from the tool. What can I do? We can edit. Do I have to remember or save your presentation? There's the one page and at least I was like skipping quickly through that maybe I should not manual page of the tool but there is a new manual page that will be in the next upstream release that lists all the policies in the detail the supported policies and of course with the interaction of custom crypto policies we will have to provide something like this listing all the custom policies on the system and and so on but this is not yet important. The question was whether there could be some verbose mode which will like show show the what the actual policy applied is and so on. Currently yeah thank you for the suggestion for improvement. Okay we are out of time so