hpr-knowledge-base/hpr_transcripts/hpr1670.txt

Episode: 1670
Title: HPR1670: Digital Signatures and Certificates
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1670/hpr1670.mp3
Transcribed: 2025-10-18 06:43:41

---

its Friday 26th of December 2014. This is an HBR episode 1,670 entitled Digital Signature,
and Certificate, and in part on the series Privacy and Security. It is hosted by U.K.
and in about 18 minutes long. Feedback can be sent to Wilnick at Wilnick.com or by leaving
a comment on this episode. The summary is this episode looks at secure connection between
U.M. and website. This episode of HBR is brought to you by An Honesthost.com. Get 15% discount
on all shared hosting with the offer code HBR15. That's HBR15. Better web hosting that's
honest and fair at An Honesthost.com.
Hello, this is Ahuka, welcoming you to Hacker Public Radio and another in our ongoing series
on security and privacy. And this time I want to talk about two things that are actually
very related, although you may not have known that, Digital Signatures and Certificates.
Digital Signatures are something very important in understanding security on the internet. While
we've seen it in the context of personal email, the applications are much broader, in particular
the use of certificates to establish communication. Recall from our discussion of email that there
are two things you can do with an email using PGP or GPG. First is you can encrypt the message,
which you do using the public key of the recipient, and then they can decrypt the message using their
private key. The other was putting a digital signature on a message. But how does that work?
Well, we saw in the last tutorial that asymmetric encryption generates two linked keys, which
can be used, each of them to decrypt with the other one has encrypted, but they cannot be used to
decrypt what they themselves encrypted. And that is the key, if you will pardon the pun, to
understanding digital signatures. When you digitally sign a message, you are using your private key
to encrypt the message itself, which gets added to the bottom of the message. But this is not
done to obscure the message at all, since the message is also sent in the clear in the email.
Your recipient can then use your public key to decrypt the digital signature, get the message back
from the encrypted form, and compare it to the message as it was sent in the clear. If they match,
you have established two things. First, because your public key successfully decrypted the message,
we have established that it was you who sent it. Your public key can only decrypt messages that
were encrypted by your private key in the first place. And, because the message is matched,
we have established that the contents of the message have not been tampered with en route.
When you understand how this works with email signatures, you are well on the way to
understanding how certificates work, since the technology is very similar. In fact, some
definitions of digital certificate start with the signing of emails, but what I want to do now
is move to understanding how certificates work on the web, which is where we most commonly encounter
them. Now, the first thing I want to bring up, an acronym, Transport Layer Security.
Now, that's how you establish a secure connection to a website, among other things.
It is the successor to the Secure Sockets Layer, or SSL, which was created by Netscape in the 1990s.
TLS is more secure, but it does include a mechanism to downgrade to SSL 3.0, if necessary.
Most people use these terms interchangeably, but the technologies are not equal.
And you always want to be using TLS. Fortunately, in most cases, this is all handled behind the scenes
in a negotiation between your browser and the remote site. TLS works much like email encryption.
A symmetric encryption is used to establish a connection and to validate the identity of a site,
then a symmetric key is exchanged and used to securely communicate both ways.
As we saw previously, a symmetric encryption is very useful for establishing a connection
when there is no shared key, but it is not computationally efficient. So switching to a symmetric key
once the connection is established speeds things up considerably. Another similarity to email
encryption is that establishing trust has issues. We saw that PGP keys are signed by people,
as part of what we call the web of trust, which, while not perfect, does provide some measure of
assurance that the key you are using does in fact belong to the person you are communicating with.
All of these issues apply as well with digital certificates.
Establishing trust means signing the certificate, and this is done by a certificate authority.
Symantec, which bought Verisign's SSL business, is the largest, and GoDaddy is also significant here.
For Utrivia Buffs, one of the early authorities was a company called Thought,
THWTE, which was owned by some guy named Mark Schulloworth. He later sold the company for a large
pile of cash and then founded Canonical, the creators of Ubuntu Linux.
X.509 is the standard adopted by the International Telegraphic Union for managing secure communications
and dates back to 1988 in its original form. It establishes the role of certificate authorities,
set standard formats for certificates, and so on. The model this standard adopted for establishing
trust is hierarchical, which is different from the Web of Trust model we saw with asymmetric encryption
and email and people signing each other's keys. Everything in the hierarchical model starts with
a root authority, which testifies to the authenticity of a certificate by adding its own digital signature.
These root authorities can sign certificates for other authorities, who can then issue certificates
and so on. Most browsers come with a pre-installed set of certificates for the largest online sites,
so that a connection happens very quickly. But if you don't have a certificate,
you need to go through a handshake process to create a connection and obtain a certificate.
X.509 certificates include a number of things, and I won't list all of them. If you're curious,
there's a Wikipedia page in the show notes that has more information. But among the specific items
it includes are the version, the serial number, the algorithm ID, the issuer, the validity,
and the public key. The first three items, version, serial number, and algorithm ID are important
for setting up a connection, as we will see. There is a negotiation between your browser and the
server to establish the specifics of the encryption protocol to be used. Issuer is of course important
in establishing how reliable the certificate is. If it is signed by a respected certificate authority,
it is considered most trustworthy. Whereas if it's a self-signed certificate, it is somewhat questionable.
So why do people use self-signed certificates? Well, the ones from the certificate authority
can be very expensive. As I mentioned previously, Mark Schuttworth became a wealthy man
through owning a certificate authority. These certificates can run thousands of dollars and
need to be renewed every few years. Validity is an important field, not always handled properly.
Recall that when we looked at email encryption, we noted that a key pair is usually created with
an expiration date, and then a new key pair needs to be created. Similarly, a certificate has valid
dates during which it should be accepted. And if you are outside those dates, your browser should
reject the certificate and throw up a warning. It is important to note here that the end user
is allowed to make insecure connections if he wishes, but a good browser will at least warn you
of the problems. If you get one and just click OK without too much stock, well, you deserve what
you get. There are a lot of issues around validity and more than just dates are involved. We will
get involved. We will get to that in more detail in another tutorial. Finally, the certificate must
include the public key which you can use to set up a secure connection. This can be complicated,
as we will see below in the handshake process, but the symbol idea is that when you generate a
key pair, you get two keys, which we could call A and B. If anything is encrypted using A,
it can only be decrypted using B, and anything encrypted using B can only be decrypted using A.
It is kind of arbitrary which one is public and which one is private.
So if the server wants to send you a symmetric key to use for communication, it encrypts the
symmetric key using its private key, and then you can decrypt it using the server's public key.
Now, the handshake, important part of this process, I'm not going to get any possible detail that
would probably take me several tutorials by itself, and it's not altogether clear that there's
enough value to make it worth doing that. I have another Wikipedia site you can go do to get more
details, but in essence, here's the general pattern, you send the server a message asking to create
a secure connection. Now, there is a browser plugin from the Electronic Frontier Foundation,
which I recommend highly called HTTPS Everywhere, and as the name implies, it attempts to create
an HTTPS connection to every site. Well, HTTPS means secure using transport layer security,
so in other words, if you're attempting to create that, you're saying give me a certificate.
Now, this plugin is available for Chrome, Firefox, Opera, and Firefox for Android, so I highly recommend
you install this. You can also manually request a secure connection by typing the URL using HTTPS instead of
HTTPS. Now, some sites may not offer secure connections. Note what we said about the cost of certificates,
but Google does it by default for all of its properties, and just as I'm recording this within the
last week or so, they announced that they are going to have that influence the ranking of sites,
so that a website that has a certificate that has secure connections will rank higher in the search
results. I'm not sure that's good in every conceivable circumstance, but certainly for any site
that is trying to be authoritative or do e-commerce, that becomes very important. I would never enter
my credit card number on a site that was not secure, that did not have that kind of connection.
Alternatively, the server may decide to go to a secure connection and send a message to your browser
telling it to move to a secure mode. Modern browsers are not going to have any trouble with it,
and I would have trouble thinking of a browser that does not have some sort of certificate mechanism
built into it. So, one or the other either you or the server says, I want to do this secure,
so we've established that. So, now, there has to be a negotiation. What is the precise encryption
protocol? There's a number of them, and in general, the negotiation is to find the highest level of
security supported by both your browser and the server. Now, once this is agreed, the server
will create a symmetric key using the agreed protocol, encrypt that key with its own private key
and send it to your browser. Your browser then decrypts this using the server's public key,
and now both sides can use the symmetric key to communicate securely.
Finally, a session ID is established that allows an interrupted session to be resumed without
going through the whole handshake process again. This is the essence of the handshake.
If you want to dig into all the details, there's a ton of stuff about, well, if this happens,
what do we do? And if this other thing happens, we'll handle it this way. But if you're into that,
go to that Wikipedia site that I put in the show notes and read up to your heart's content.
But there are places where things can go wrong. Our next tutorial is going to deal with some of
those. Now, one thing you might want to keep in mind is that this technology does more than
just connect you to a website securely. In general, when you hear someone talk about
certificates in any security context, this is what they are talking about. For instance,
the dreaded UEFI Unified Extensible Firmware Interface and its related secure boot
uses X.509 certificates issued by Microsoft, and in this case, Microsoft is the certificate
authority to validate the software that is allowed to boot on a system that employs secure
boot. So if you get to know how this works on websites, you already understand much more than that.
So with that, this is Ahuka signing off for Hacker Public Radio and reminding you as always to
support FreeSoftware. Bye-bye!
Hacker Public Radio was founded by the Digital Dove Pound and the Infonomicom Computer Club,
and is part of the binary revolution at binwreff.com. If you have comments on today's show,
please email the host directly, leave a comment on the website or record a follow-up episode yourself.
Unless otherwise status, today's show is released on the Creative Commons,
Attribution, ShareLite, 3.0 license.