Up next in 10
SSL vs TLS Explained in 8 minutes
0 views
Jul 1, 2025
🔐 Want to learn hacking, Web3, dark web, Blockchain and cybersecurity? get access to real-world web hacking, bug bounty, and reverse engineering courses + a private discord and tools: 👉🏼https://whop.com/policypoint/ SSL vs TLS Explained in 8 Minutes! Ever wondered about the difference between SSL and TLS? In this quick and informative video, we demystify the complexities of internet security protocols in just 8 minutes! Whether you're a beginner looking to boost your tech knowledge or an enthusiast keen to understand how your data is protected online, this concise guide is tailored for you! We break it down with easy-to-understand visuals and clear explanations. Don’t let jargon hold you back—equip yourself with the knowledge about SSL vs TLS today. Hit play and get secure! Don't forget to like and subscribe. Buy SSL https://ssls.sjv.io/do72Mq Hostinger https://hostinger.com?REFERRALCODE=1NWAKPA19 ____________________________________ Telegram https://t.me/Policy_Point _______________________________________
View Video Transcript
0:00
What is an SSL handshake? Well, I'm glad
0:02
you asked. Let's talk about it. But
0:03
before you can be initiated into the
0:05
secret society of cyber security and
0:07
learn the three-way handshake, you need
0:09
to know what SSL and TLS actually are.
0:12
SSL stands for security socket layer and
0:14
is a protocol that encrypts data
0:16
transmitted between computers. And TLS
0:18
or transport layer security is
0:20
essentially a newer version of SSL, but
0:22
with better security practices. Did you
0:24
know that SSL actually doesn't exist
0:26
anymore? The protocol is a bit dated as
0:28
it was made back in 1995 and it was
0:30
depreciated way back when and has been
0:32
replaced with TLS. But the name SSL is
0:34
so catchy and so bus as the kids say, we
0:37
just keep using it. So just know that in
0:39
typical usage SSL is actually referring
0:41
to TLS or some other form of security
0:43
protocol. Speaking of protocols and
0:45
security, let me tell you some bad news.
0:47
There is no such thing as a cloud. Cloud
0:49
storage is literally just somebody
0:51
else's computer. Nobody is actually
0:53
sending the photos of your cat or what
0:55
you ate last night for dinner up into a
0:56
cumulo nimbus. It just doesn't happen.
0:58
We hear words like internet, cloud
1:00
servers, serverless servers or whatever,
1:02
but overly simplified. The entire
1:04
internet is just a bunch of cables
1:05
connecting your computer to somebody
1:07
else's computer. So when you are
1:08
connected to the internet, you are
1:10
sending data, sometimes very personal
1:12
data through a lot of cables and through
1:13
a lot of other people's computers. And
1:15
that is very useful, but it is also a
1:17
massive security risk. For example, when
1:19
you're purchasing something online, you
1:21
are sending your credit card
1:22
information, date of birth, and current
1:24
address through a lot of other people's
1:25
computers. Now, call me old-fashioned,
1:27
but that sounds a little risky. This is
1:29
where SSL comes in. SSL offers a few
1:31
layers of protection by encrypting data
1:33
sent between the server and the end
1:35
user, making it a bit more secure. You
1:37
can tell at a glance if a server is
1:38
using SSL by looking at the URL. If it's
1:41
just HTTP, it's unsecure. If it's using
1:43
HTTPS, the S stands for secure and is
1:46
using some form of encryption. So, how
1:48
does SSL or TLS actually work? When you
1:51
visit a website that uses SSL, your
1:54
browser and the website server engage in
1:56
what's called a handshake to establish a
1:58
secure connection between the two. The
1:59
security handshake is a complex process
2:01
that involves several steps, and that
2:03
will vary depending on what type of
2:04
server and client device you are using.
2:06
But the main thing that we need to know
2:08
is that SSL works to ensure the
2:10
communication between the browser and
2:11
the server is encrypted and secure.
2:13
Here's a bird's- eye view of what
2:14
happens in that handshake. The security
2:16
handshake begins when the user's browser
2:18
sends out a client's hello message to
2:20
the server. This message includes
2:22
information about the browser, the
2:23
operating system, and the encryption
2:25
algorithm that the client can support.
2:27
The server then receives that client
2:28
hello message, and based on the client's
2:30
info, will choose which type of
2:32
encryption they will use going forward.
2:33
By default, the server will choose the
2:35
most powerful encryption that the
2:37
browser, the user device, and the server
2:39
can support. This is why you shouldn't
2:41
use sketchy or discontinued web
2:43
browsers. I'm looking at you hardcore
2:45
Internet Explorer fans. It's time to
2:47
move on. Once that's done and your tears
2:49
have all dried up, the server responds
2:51
to the client hello message with a
2:52
server hello message. This message
2:54
includes information about the server
2:56
and the selected encryption algorithm
2:58
that will be used. The server also sends
3:00
its digital SSL certificate, which
3:02
contains its domain name, certificate
3:04
authority, and the public key that will
3:06
be used for encryption. The client's
3:07
browser then checks the server's digital
3:09
SSL certificate to ensure that it is
3:11
valid and issued by a trustworthy
3:13
certificate authority. One who signed or
3:15
vouches for that particular SSL
3:17
certificate. Side note for all my site
3:19
owners, you will need an SSL certificate
3:21
and two because of how fast bad actors
3:23
can work their magic. Your SSL
3:24
certificate will expire and needs to be
3:26
changed after a short period of time,
3:28
typically every 90 days. Any modern
3:30
browser will pretty much go out of its
3:32
way to stop users from connecting to a
3:33
site that has an expired SSL
3:35
certificate. So consider yourself warned
3:38
and make sure that your SSL is up to
3:40
date. Now back to the handshake. If the
3:42
browser finds that the certificate is
3:43
valid, the browser generates a random
3:46
session key and encrypts it with the
3:47
server's public key for the certificate.
3:49
That encrypted session key is then sent
3:51
back to the server and the server
3:53
decrypts the session key using its own
3:55
private key and verifies that the
3:57
session key matches the one that was
3:59
generated by the browser before. If the
4:01
session key is valid, the server then
4:03
generates a finished message and sends
4:05
it off to the user. The browser then
4:06
sends a finished message of its own back
4:08
to the server which includes a message
4:10
digest of all the previous messages
4:12
exchanged during the handshake. If both
4:14
the server and browser have successfully
4:16
verified each other's messages, a secure
4:18
connection is established and all
4:20
subsequent communications between the
4:22
browser and server will be encrypted
4:24
using that session key. That's a brief
4:26
summary of how SSL handshakes work.
4:28
There is more to it, but for most people
4:30
that's deep enough. We have more on our
4:32
blog on this subject. If it interests
4:33
you, check the description box down
4:35
below. if you're interested. So, when
4:37
should you use SSL? SSL should be used
4:40
pretty much all the time, but especially
4:42
whenever sensitive information is
4:43
transmitted online. This includes
4:45
obvious information like credit card
4:47
information and social security numbers,
4:49
but also includes personal information
4:51
such as passwords, username pins, forms,
4:54
email addresses, home addresses, phone
4:56
numbers. Anything and everything that is
4:58
unique to your users should be
4:59
encrypted. You get the idea. So, how do
5:01
you get SSL? First, you need to get
5:03
what's called an SSL certificate. An SSL
5:06
certificate is a unique digital
5:08
certificate that proves and
5:10
authenticates the identity of a website
5:12
and is used in the handshake to
5:13
establish a secure connection between
5:15
your computer and the server. SSL
5:16
certificates are available in both free
5:18
and paid versions. The free and easy way
5:20
is to use Let's Encrypt. Let's Encrypt
5:22
is a nonprofit certificate authority
5:24
that is trusted by web browsers and
5:26
gives free SSL certificates to website
5:28
owners. Paid SSL certificates are issued
5:30
by commercial certificate authorities
5:32
and with a quick Google search you can
5:33
find plenty of them. Free SSL
5:35
certificates are an excellent option for
5:37
websites that have low traffic and do
5:39
not handle extremely sensitive
5:40
information. They are also ideal for
5:42
websites that are starting and need to
5:44
keep costs low. However, free SSL
5:46
certificates may not offer the same
5:48
level of security as paid SSL
5:50
certificates. Paid SSL certificates are
5:53
recommended for websites that handle
5:55
sensitive information such as credit
5:56
card numbers and personal data. They
5:58
offer higher levels of security and come
6:00
with warranties and insurance policies,
6:02
which is a very nice feature just in
6:04
case you get hacked. Therefore, if you
6:05
run a medium to large e-commerce website
6:08
that performs lots of online
6:09
transactions, maybe a paid solution is
6:11
right for you. I can't tell you which
6:13
one is right for you and your use case,
6:14
but I can tell you that if you can't
6:16
afford a paid version, at least get a
6:18
free version because it's free and it
6:20
works. But whatever you decide to do,
6:21
you should be monitoring your site and
6:23
make sure that it is always secure with
6:25
a tool like Simon Synyn Synthetics. With
6:27
our tools, you can be sure that your
6:29
users are securely connected to your
6:30
site by monitoring your SSL certificates
6:33
validity. You can also run speed tests
6:35
from anywhere around the globe to make
6:37
sure that your site is not only safe,
6:38
but is also technically outperforming
6:40
your competitors. Link to a free trial
6:43
down in the description box below. By
6:45
the way, do you know that there's so
6:46
much I can't share on YouTube? Whether
6:48
it's because of platform rules or
6:50
because some skills need deeper hands-on
6:52
explanations. Many of my videos got
6:54
deleted and that's why I created a
6:56
policy point learning community for you.
6:58
A place where I can share everything
7:00
when you join. You're not just getting
7:02
another course. You're getting access to
7:04
complete ethical hacking guides. The
7:06
tools and techniques I wish someone had
7:08
handed me when I was starting out. And
7:09
here's the kicker. This is the stuff I
7:11
don't teach on here. No watered down
7:13
content, no clickbait, just raw,
7:15
actionable knowledge. On top of that,
7:17
you'll join an exclusive community on
7:19
Discord. I pinned the link in the
7:21
comments section below, but it's not for
7:22
everyone. The link is only available for
7:24
those who are serious about the journey.
7:26
If you liked this video, be sure to give
7:28
it a like. If you want to learn more,
7:30
consider subscribing to Policy Points,
7:31
as we are always making new tech
7:33
content. New tech company.
#Hacking & Cracking
#Web Services