What is a TLS Cipher Suite?

[@sobia09cs01muet]

I have seen a lot of videos on KZbin about TLS but your explanation is very easy to understand. Great Work :)

[@devcentral]

glad you enjoyed it!

[@notta3d]

Great introduction. Thanks for posting.

[@devcentral]

Thanks for the comment and glad you enjoyed it!

[@MyLifeNavigation]

I always search the topic on your youtube page when I find something difficult to understand. You never disappoint me :) Great Work!

[@devcentral]

glad you enjoyed it! and, let us know if you have any topics we should address.

[@kenaverill601]

Extremely well explained and with precise detail. It has opened a much better understanding for me now across all suite functions!

[@KDOERAK]

excellent TLS cipher suite introduction: short, informative, easy to understand

[@devcentral]

glad you enjoyed it!

[@prowlerpunk]

GREAT content, to the point explanation.. I subbed to you, cuz yours is better than others out there

[@devcentral]

Thanks and appreciate the comment (and sub) 🙂

[@herolawole1152]

A very Clear explanation. Awesome. Thanks

[@devcentral]

Glad you enjoyed and we appreciate the comment!!

[@jamesmcgraw8392]

This helped significantly with my cybersecurity course. Thank you.

[@devcentral]

I'm glad it helped!

[@tiffanyhickman7460]

@@devcentral hey

[@pavel9652]

This channel is an instant sub! You guys deserve more subscribers. Excellent quality, especially videos published in the last few years are great!

[@devcentral]

glad you enjoy the videos!

[@vinitbhardwaj8403]

Perfectly Explained. The puzzle is solved now. Kinda.

[@terrancepinkney777]

100% Totally subscribed to your channel! The way you explain things is a bit how I see things and try to break it down in my mind like this. Not overly technical yet you incorporarte all the pieces of this topic very well. Thanks for your awesome work!

[@devcentral]

glad you enjoyed it!

[@JH-fs3lz]

how does this mans write backwards so well

[@joannakonyeha]

All makes perfect sense now. Thanks for taking our time to put this together.

[@devcentral]

glad you enjoyed it!

[@juandavidaragon4361]

Thank you so much. The video is easy to understand, I love it!

[@devcentral]

glad you enjoyed it!

[@rosshoyt2030]

Absolutely great overview that brings together these many topics. Thanks!

[@devcentral]

glad you enjoyed it!

[@matingarastudios]

Nice job. I’m working on a presentation for my engineers and you’ve answered quite a number of my questions.

[@devcentral]

glad you enjoyed it!

[@ahahahabmbc1075]

Thank you, thank you!

[@devcentral]

Glad you enjoyed it!

[@katen8769]

Thank you 1000 times

[@devcentral]

Glad you enjoyed it!

[@TechieDheeraj]

Thanks John for this, As usual your explanation is to the point. I follow your videos even if I don't need to work on that particular tech.

[@devcentral]

i'm glad you enjoyed it!

[@amvk_999]

awesome explanation🙏

[@paolung]

I'm just impressed he can write backward like that.

[@rosshoyt2030]

They just reverse the video (left to right) after recording, he's writing normally. I had the same thought though at first 😄

[@paolung]

@@rosshoyt2030 Makes sense, he was writing REALLY well backwards :D

[@devcentral]

Here's our LBL Behind the Scenes video: kzbin.info/www/bejne/i2iokH9qrKiDisU

[@katen8769]

Thank you 1024 times.

[@devcentral]

haha! :) Glad it was helpful for you!

[@juliantoon4502]

good explanation

[@devcentral]

Thanks for the note!!

[@otazka2476]

this guy is great

[@devcentral]

We really appreciate the comment and glad you enjoyed the video!

[@CyberTronics]

Very beneficial thank you

[@Momo-qk3wi]

Clear and concise.... Thanks a lot

[@Meritumas]

Super clear, thank you for doing fantastic job explaining complicated stuff.

[@devcentral]

glad you enjoyed the video!

[@misakiwang9591]

Help me alot with my tutorial. Glad that I found your video!

[@devcentral]

Glad you enjoyed it!

[@ravisattigeri_1]

Notes : Protocol --> TLS 1.2, TLS 1.1, TLS 1.0, SSLV3, SSLV2 Key Exchange --> ECDHE, RSA Authentication --> RSA, ECDSA CIPHER --> AES, GCM/CBC, Camellia, DES, RC4, RC2. MAC --> SHA, MD5 TLS CIPHER SUITE ECHDE(KE)-RSA(AUTH)-AES128(BulkEncry/SE)-GCM-SHA256 HEX Representation - 0XCO2F

[@bushbavo]

What a great video!! You made it so simple and presice. Will definitely share this up with my colleagues. Keep doing a great job

[@devcentral]

glad you enjoyed it!

[@HARISHANKAR-oy5hl]

100% clean session thanks for knowledge

[@devcentral]

glad you enjoyed it!

[@rdshenai]

One of the best videos on cipher suites!

[@devcentral]

glad you enjoyed it!

[@011azr]

You explain this very clearly. Really, much thanks to you guys :)))

[@devcentral]

Thanks!! Appreciate the comment!

[@rogerredhat1431]

Nicely explained, filled some gaps in my understanding. Thank you!

[@devcentral]

i'm glad you enjoyed it and found it helpful!

[@techieadam5031]

Wondered how they all fit together, thanks!

[@devcentral]

Happy to help!

[@4976436]

You make my day. Awesome 😎👍

[@devcentral]

Thanks and we appreciate the comment!

[@g4rdo984]

very clear and understandable the way how u explained it, thank you very much for ur time and iniciative to share it, greetings :)

[@devcentral]

glad you enjoyed it!

[@pickiziziz]

Thanks John for the detailed explanation for a complex topic like this. Before reaching here , i was under the impression that the servers certificate public key will be used to encrypt the initial handshake and hence work as the key exchanger. Now if cipher suite also has a key exchanger algo , which one is used in such case?

[@devcentral]

Hi pickiziziz...great question! The server's public key can be used as a part of the key exchange (if the key exchange algorithm is RSA), but it doesn't have to be used for key exchange. In fact, most servers/browsers now prefer Diffie Hellman key exchange (many times using Elliptic Curve as well) instead of RSA. The server's private key will still be used for authentication purposes (to prove to the browser that the server is the one expected), but the server's private key doesn't have to be used for the key exchange. That's one of the reasons that the cipher suite is agreed on early in the TLS handshake process so that both sides will know what key exchange algorithm to use. I hope this helps!

[@joshuaeuceda4635]

Thank you nice job!!

[@devcentral]

glad you enjoyed it!

[@amokrani]

great job thank you!

[@devcentral]

Glad you enjoyed it!

[@PaulOfford]

Great video, John. A big help.

[@devcentral]

glad you enjoyed it!

[@NicoleCaguicla]

Thank you for your video! I have a question, let’s say there are many clients connecting to 1 server. Is it possible that all this clients and server share the same cipher suite to establish secured connection?

[@devcentral]

Great question Nicole! The short answer is, yes...all clients could use the same cipher suite. To be clear, though, the fact that the same cipher suite is used by multiple clients does not mean that all those clients use the same key for encryption. Each client will have their own shared (secret) encryption key with the server. The cipher suite simply defines what type of encryption algorithm is used between the client and the server. But the actual key used between the two will be different for each client/server connection. An analogy might be something like this: several people want to drive from their personal house to the bank. Each one has an option on what kind of car to drive (Honda, Chevy, Ford, Toyota, etc). All of the people could theoretically choose to drive a Toyota car, but each car is different even though they are all Toyota (even the same make/model). So, even though you drive a Toyota doesn't mean you can go to another Toyota and take your car key and use the other car. The same is true for cipher suites. You could use the same cipher suite as another client, but that doesn't mean your secret encryption key is the same as theirs. I hope this helps!

[@balamaheshjampani9074]

I didn't understand at 13:43, signing the hashed certificate part. Rest of the video is great.

[@tushar8133a]

Superb!

[@devcentral]

glad you enjoyed it!

[@shrutichincholkar9964]

Totally Perfect explanation 🙌

[@devcentral]

glad you enjoyed it!

[@HughJass-313]

❤❤

[@Gaurjain]

Protocol Protocol : TLS 1.3, TLS 1.2 Key Exchange : EC DHE, RSA Auth : RSA, EC DSA Bulk Cipher : AES, GCM/CBC, DES MAC : SHA(secured), MD5(not secures) certificate sent from server has MAC

[@vahedonabedian2272]

Thanks John, great explanation.

[@devcentral]

thanks for the comment!!

[@hamzabashir1791]

Really helpful for understanding TLS suites... Now i can understand more...👍🏻 Thanks for the video...😎

[@devcentral]

glad you enjoyed it!

[@hamzabashir1791]

F5 DevCentral looking into your videos one by one n they are too good ... by the way can you do video on TLS 1.2 handshake....👍🏻

[@devcentral]

@@hamzabashir1791 Hi. We recorded a couple of videos on the TLS handshake. Here they are: kzbin.info/www/bejne/maa1YWivlJd6rsU kzbin.info/www/bejne/pJDHYqV5jbOlrpI

[@bigkeoni6429]

Hi John, you had mentioned about pointing to some official documentation for the SSL hexadecimal designations. Is that under OpenSSL?

[@devcentral]

Hi John...sorry about the oversight on posting that list. Here it is: testssl.sh/openssl-iana.mapping.html I hope this helps!

[@jackli1352]

try openssl ciphers -v command, you will got the tls cipher suites supported on your server

[@devcentral]

Thanks for the info!

[@ivanlora5318]

Great Work!! Now it is more clear to me

[@devcentral]

I'm glad you enjoyed it!

[@nitinvats3165]

This really helpful. Thanks for putting in the efforts.

[@devcentral]

glad you enjoyed it!

[@nitishwadhawan840]

Nicely Explained and Very Helpful ..!! Just a Question , When Server Signed the Hash of Certificate then How Client authenticate that this is the Server to which i am looking for using the SHA or MD5 ?

[@Gowrilekshmi2021]

very nice explanation.Thank you

[@devcentral]

glad you enjoyed it!

[@sharathbv1419]

Good explanation. Quick question, If BigIP LTM has an SSL profile with cipher 'Default@strength' , does it force to negotiate strongest available cipher suite with the client or server?

[@devcentral]

Great question Sharath! When @strength is used with the DEFAULT cipher list, then the ciphers are ordered on the server according to their strength (for example, 384 bit would be listed before the 256 bit, etc). When a client begins secure communications with the server, the client offers up it's set of cipher suites (already built into the browser..each browser is built slightly different) and then the server goes down its list of ciphers in order and it chooses the first match it can find. Maybe it matches the very top-listed cipher, but maybe not. As long as one of the cipher suites matches, then the server will pick it and that will be the cipher suite used for that secure session. Thanks!

[@ashuniet]

it depend upon how your priorities your ciphers.. if you using Custom Suites.. in DEFAULT one they put the higher key size strengthen top on the order

[@zonereyrie]

@@ashuniet The ordering of the cipher suites varies by TMOS version - but in 'DEFAULT' it is *not* normally the strongest suites which are listed first. A number of factors go into the ordering, but to generalize it is a balance between security and performance. (Higher bit cipher suites use more resources, and thus reduce performance of the box.) Using '@STRENGTH' in the cipher suite configuration will force sorting by key size, but this can be deceptive as well. What is more secure, a cipher suite using ECDHE and AES128-GCM or one using RSA and AES256 (CBC). I'd argue that the former is a better choice, but the latter will come first in the list because of the larger key size.

[@coozable]

Very impressive :-) This really helped me understand Much better. Though i might just have to watch it a few more times to remember it all ;-)

[@devcentral]

glad you enjoyed it! and, feel free to watch as many times as you need!

[@sarveshgupta3802]

Impressive content and explanation. Thanks for it.

[@devcentral]

glad you enjoyed it!

[@WndSks]

RC4 is a stream cipher, not a block cipher.

[@devcentral]

Thanks WndSks! When I was listing the symmetric encryption algorithms, I slipped a couple of times and said "block" and then followed up with "bulk" to clarify that I was referring to symmetric, bulk encryption algorithms as opposed to asymmetric key exchange algorithms (RSA, DH, etc) or hash algorithms. But, thanks for the reminder that RC4 is, in fact, a stream cipher not a block cipher...an important detail in the case of symmetric algorithms!

[@vladisergeiev7278]

8:59 Is that accurate? I thought public key is only used for encryption when sending data back to the server. If it was used for decryption of private key encrypted data, then the data itself would be compromised.

[@simpleguy5889]

That one caught my attention as well, the video lost its credibility after this statement was made. These are dangerous statements as it messes up the very foundational concepts of client-server encryption. I think the author is confused.

[@miomio134]

what author explained here is digital signature signing process.

[@vladisergeiev7278]

@@miomio134 Digital signing process is HMAC, whereby content is signed with private key and verified with private key. I'm not sure that's what he explained.

[@gkdusa]

What if the cipher is null for output of openssl command . Does that mean that version of TLS is disabled ?

[@adamking1491]

It has just made a sense,I guess :) Thanks a lot.

[@devcentral]

glad you enjoyed it!

[@kallikantzaros]

thank you so much

[@devcentral]

glad you enjoyed it!

[@subhamthemusicalguy8851]

Very informative and useful video

[@KnivesTV]

Very helpful, thanks.

[@devcentral]

glad you enjoyed it!

[@humbertogonzalez2613]

Hey Man, just want to thank you for the great explanation - better impossible

[@devcentral]

glad you enjoyed the video!

[@Saemundrthepure]

You mentioned a link to BIG IP specific documentation on turning those on or off. Could you link that for 14.x? I need to block RC4, and not sure how.

[@pedrodominguez5418]

PCI vendors are requesting only stitched cipher suites, what are stitched cipher suites?

[@devcentral]

From Stackexchange: security.stackexchange.com/questions/204429/what-is-a-non-stitched-ciphersuite

[@CairosNaobum]

Thank you for this videos !

[@devcentral]

I'm glad you enjoy them!

[@shaishankar8499]

Nice explanation. Just a quick question, Wireshark will show the cipher suite selected between client and server. Will that not be a risk?

[@zonereyrie]

At least through TLSv1.2 the cipher suite negotiation happens in the clear, so you can always see which cipher suite is selected. This is not a risk (beyond the use of a weak suite, which is a risk in any case) as the strength of the system is in the secret keys.

[@davisli]

Check out Perfect Forward Secrecy or sometimes called Forward Secrecy. Also, note the concept Ephemeral. scotthelme.co.uk/perfect-forward-secrecy/

[@vimaltewari6969]

Very Informative. Thanks.

[@devcentral]

glad you enjoyed it!

[@kc3020]

awesome

[@devcentral]

thanks!

[@bimboyaquino7091]

Can this cause disconnection of websocket traffic? TLS handshake error?

[@abhaypratap5311]

How to check whether given cipher suite is strong and weak generally malware choose weak cipher suite so is it right to say that malware prefer weak cipher suite, old like RC4, RC2 .

[@devcentral]

Great comment Abhay! I'm working on another video that goes into detail on which TLS cipher suites are strong and which are weak...stay tuned!

[@zonereyrie]

I don't think you can generalize that way. Modern malware using encrypted communication is likely to be using the latest functionality - ephemeral key exchange, AES-GCM, etc. Supporting these is just as easy as an older algorithm - authors are using available libraries. Strength isn't a clear linear scale either - it isn't just key size. AES256-CBC has a larger key size than AES128-GCM, but the latter is arguably a better choice in a real world deployment given the growing number of attacks on CBC ciphers. And, for the same key size, GCM is generally a higher performing option (less load). And does your application really need 256-bit keys? There is also the temporal factor - a mid-strength ECDHE key exchange is probably a better option than a high-strength RSA key exchange. The latter is generally used for many sessions and can be recovered later to decrypt everything it was used on. The former is used for one, or few, sessions and so breaking the key recovers less information. Always tradeoffs.

[@abhaypratap5311]

So what are the other way to test whether cipher suite strong and weak... actually I have tested my client browser compatibility in ssl lab website so it shows preferred cipher suite and u said malware uses good strength of communication in my opinion few types of malware uses good encryption standard but not all, I have also read research paper related to this topic so that's why I am sharing my knowledge what I got correct me if I am wrong and if u good source related to this please share it thanks.

[@addanametocontinue]

There arguably is a cipher suite that could be considered to be the most secure, I suppose. However, forcing all clients and servers to use that presents a few problems: 1. Some servers may not support that specific suite without having to upgrade. The most secure suite is ever-changing. Ideally, all companies will maintain their systems to keep them up to date, but we know that's easier said than done. 2. Many of the larger browsers don't make it easy for you to force it to only use specific suites. You'd have to dig through registry settings, etc. For now, we have to rely on 2 solutions to avoiding the usage of insecure suites: 1. Hope that modern browsers will disable the usage of insecure cipher suites as they roll out new versions of the software. This way, if you try to connect to a server that doesn't support one of the more secure cipher suites, the connection is rejected. 2. Hope that server administrators disable cipher suites that are considered insecure. This way, if the client tries to connect and their browser only supports insecure cipher suites, the connection is rejected.

[@Gaurjain]

EC-DHE key exchange (smaller keys with elliptical curve and perfect forward secret with Diffy Hellman Ephemeral)

[@wazirzafar29]

how to fix the SSL anonymous cypher suite supported vulnerability on linux machine

[@3err0]

great video tho i'v lost couple of hours on figuring authentication and MAC parts, but can someone confirm if i got this right: Authentication part-(RSA for example) is about verification of certificate in TLS handshake phase, which is done via digital signature: sender encrypts hash of message via MAC algorithm(SHA for example), with its private key , which reciever decrypt with senders public key (from certificate) And MAC part is preformed in "TLS record protocol" (from RFC), that is, in actual sending of encrypted data (after handshake), in which there is MAC "tag" on each message(packet), for data integrity ?

[@gooogle-jd8sg]

how do write like that you write from right to left can you explain how you do that ??

[@HardTalk1]

I'm not good at it, but I though this process is Public key or Asymmetric and here you're using Symmetric encryption algorithms like AES, DES and RC4. so why don't we use Asymmetric Encryption algorithms? If I'm wrong I'm just learning.

[@DanielMGarcia69]

Asymmetric algorithms use complex exponential calculations which are slower and more processor intensive than symmetric algorithms. Furthermore, Asymmetric algorithms are much more stringent as to the length of the data they can encrypt. As such, asymmetric encryption is not ideal for encrypting bulk data. This is why asymmetric encryption comes in handy just for the first part of the communication (a.k.a TLS handshake). Having that established, the encrypted traffic flow can happen using symmetric encryption algorithms such as AES, 3DES and SHA, MD5 for authentication. I hope that had shed some light on it.

[@devcentral]

@@DanielMGarcia69 thanks for the great info...really appreciate the insightful response!!

[@digvijaysingh4712]

Able to make a connection with an invalid cipher(E128D:R1A:AES128:RANVIJAY:SHA238) But not able to make a connection with a valid cipher(ECDHE-RSA-AES256-SHA384) in LDAP SERVER???

[@zhengshenyu]

I don't think the cipher suites specify the protocol version, but rather just TLS or SSL.

[@devcentral]

Hi Ryan, great question! The cipher suites are designed for each specific version of SSL/TLS, and you can show the version for each cipher suite. For OpenSSL (the most common implementation on the Internet), you can type in: openssl ciphers -V and you will get a listing of all ciphers with the SSL/TLS version included. Here's a link for more info on this: www.openssl.org/docs/man1.0.2/man1/ciphers.html

[@zhengshenyu]

I got you, thanks so much for the clarification. Been watching your vids alot recently, terrific jobs!!

[@devcentral]

@@zhengshenyu Thanks! glad you are enjoying the videos!

[@ShopperPlug]

Seriously what is "TLS Cipher Suite"?... video explains it all. This "Ciper Suite" is really important, just learning how to program and becoming a good back end developer is not even close to being ready for a production safe platform. Developers really needs to understand the security of things which is extremely lacking in the DevOp world. This is just sad, no mentors in website programming have ever mentioned the importance of the security for a platform, such basics like TLS 1.3 or 1.2 and it's "Cipher Suite".

[@thoughtslibrary]

where person is writing ? is this on a glass? how is this annotation works can anyone explain it to me?

[@RolandoGarza]

Basically the expositor is writing on glass (while shining a lot of light on the board), and then flips the video afterwards on postprocessing; they made a video about it on their channel.

[@electron-Volt]

12:53 lyrics from an old Eminem song

[@anirudhreddybasani3555]

whattt?? I didn't see any lyrics there

[@Saemundrthepure]

I caught that too. :D

[@RolandoGarza]

Ha! Good catch; won't be able to not listen to that when I re-watch later.

[@eechaze12]

In some way in lay man's terms 2 foreign leaders having an exchange with an interpreter encrypting and decrypting the exchange

[@milesford99]

So for these videos, do they have a special shirt made with their logo reversed?

[@psilvas]

Nice catch Miles! You can check out this video showing how we do it: kzbin.info/www/bejne/i2iokH9qrKiDisU

[@nightcode8482]

Great explanation but did he really learn how to write inversely? From his perspective, whatever he is writing should appear as a mirror image of what we see on the video.

[@meepmeep6363]

The video is inverted.

[@ZestyVA]

Such a simple explanation for the writing!! I was watching the video trying to figure it out and I think because I fried my brain I couldn't figure it out!!!

[@theforgot3n1]

Great stuff!

[@devcentral]

glad you enjoyed it!

[@jtrapo]

I'm searching for TLS group of Michigan And in search of Rabbi A A.

[@inatrik]

I find this a bit vague on the explanations he gives