lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

150
hpr_transcripts/hpr1720.txt Normal file
View File

@@ -0,0 +1,150 @@
Episode: 1720
Title: HPR1720: 15 Certificate Issues and Solutions
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1720/hpr1720.mp3
Transcribed: 2025-10-18 08:13:13
---
This is HPR episode 1,720 entitled 15 Certificate Issues and Solutions and is part of the
series' privacy and security. It is hosted by Ahaka and is about 18 minutes long.
The summary is a look at the problems that SSL certificates can have and offers some solutions.
This episode of HPR is brought to you by an honesthost.com. Get 15% discount on all shared
hosting with the offer code HPR15. That's HPR15. Better web hosting that's honest and fair
at an honesthost.com.
Hello. This is Ahuka welcoming you to Hacker Public Radio and another exciting episode in our
ongoing security and privacy series. And what I want to do today is conclude for now our
discussion of TLS SSL certificates. Talk about some of the issues involved with them,
some possible solutions to those issues. And then we've got some other things that we'll move
into. I've already got stuff planned after this. But last time we looked at some basics about how
TLS and SSL work. And saw that this is basically an application of the same technology used to
encrypt emails that shouldn't be terribly surprising. In the Unix world certainly we hate reinventing
the wheel so if you have something that works keep doing it. We also noted though that there are
some problems with this approach. We need to recognize that in security there is never a permanent
solution and that vulnerabilities are constantly being discovered and ideally then being fixed.
Some of these may involve highly technical issues about cryptographic methods but I think the
largest category of issues is about the processes around the use of certificates. Let's start with
root certificate authorities. Now root certificates are certificates that are either unsigned or
self-signed. Because they are the starting point i.e. root of the hierarchy they are not vouched
for by any other authority. Since there is no other way for these authorities to be validated
each browser includes a list of the root authorities it trusts. You can view a list of the root
authorities that Mozilla uses for instance at a link that will be in the show notes. I've been there
it contains nearly 400 entries including as Steve Gibson likes to point out the Hong Kong post
office. Because these are considered trusted your browser will consider any certificate they issue
or sign as authoritative. But are all of these root authorities truly trustworthy? Do they carefully
evaluate each certificate they are asked to issue? The evidence suggests they are not. In July of
2014 we got a report that an agency of the government of India the National Informatics Center
had issued certificates purporting to belong to Google and Yahoo. There were 17 false Google
domains and 27 false Yahoo domains that had certificates issued. Why did this happen? I don't know
that we have the answer. Now as it happens this particular root authority was never trusted by Google
or Mozilla but was trusted by Microsoft. Of course in the wake of this revelation the National Informatics
Center was removed from the list of trusted authorities that Internet Explorer uses. But anyone
using Windows XP would not get this update since Windows XP is no longer supported.
Another issue came to light in December 2013 when Google discovered a list of fake certificates
for its domains issued by the French government. Why did the French government do this?
Quite probably to execute a man in the middle attack on Google.
Now one of the worst examples was the Dutch authority Digi Notar which was hacked by the
Iranian government and used to generate false certificates that were employed in man in the middle
attacks against Iranian dissidents. It appears that as many as 300,000 people were victims here.
So all of these involved man in the middle attacks. What does that mean?
Well a man in the middle attack is a form of active eavesdropping on supposedly secure communications.
The attacker is able to convince each side of the conversation that he is the person they think they
are corresponding with. In the context of certificates if a government can show you a certificate
that purports to be from mail.google.com it can induce you if you accept the certificate to log
into a government-owned site using your Gmail credentials. The government then has your login
and password and can inspect all of your mail at any time.
And the government system can take your credentials when you first log in,
immediately open a connection to the real Gmail with those credentials,
and then just sit in the middle as you read and send email.
Of course the Iranian government did this for evil purposes,
but are the NSA and GCHQ really any better? And what was the French government doing?
Remember, all governments regard the privacy of their citizens as a flaw and take steps to remedy that
flaw. Of course there is something similar in corporate networks, though depending on laws
in your jurisdiction it may be perfectly legal. For instance, in the United States the law says
that corporate networks belong to the employer and they can do pretty much whatever they need to do
to protect their network. This means that an employer can provide you a computer and internet
access on terms that give them control over what you do. It is common for companies to route
traffic through a proxy server and this server may use certificates to execute what is in essence
a man in the middle attack on you. The way this works is that each computer is configured
to accept self-signed certificates from the company as trusted route certificates.
When you go to your bank for instance and ask for a certificate for a secure login,
the company server intercepts the request and sends your login to your bank from the company server.
This gives them a secure connection to your bank. Meanwhile they send you a certificate
signed by their trusted self-signed route certificate purporting to be from your bank.
Your browser accepts this as authentic. You have to all appearances a secure connection to your bank
but in fact all you have is a connection to the company server. Whether or not you consider this
a good idea, I happen to think it is probably justified, you should be aware of it. It is probably
completely legal at least in most jurisdictions. Now how do you protect yourself?
I am going to rely on some ideas here from the Electronic Frontier Foundation and there's a link
in the show notes if you want to go to their site and read up more about this but they're very
good on these things. So what does EFF say are good ways to protect yourself? Number one,
always install browser updates as soon as they become available. Remember that the list of
trusted route authorities is contained in a list in each browser and any changes to that list
come in the form of a browser update. In the case of the Indian Authority, Microsoft issued an
update to remove it from the list but until you installed the update you could be at risk.
Second, check for certificate revocation. If a certificate is bad it should be revoked and you
should be able to see this. Unfortunately this is not available for Google Chrome because their
security team has decided that revocation lists don't work well. I think this is a mistake
and would not be surprised if public pressure caused them to relent at some point.
Firefox does handle it quite well. The recent Heartbleed vulnerability really highlighted
this issue because it potentially compromised many sites and caused a spike in certificate
revocations by sites that might have been affected. Another Firefox option is to install the
convergence add-on which warns you if the certificate you are seeing is not what the people
and the rest of the world are seeing. And also another Firefox add-on certificate patrol
which will alert you when a certificate has been updated. This gives you additional information
you can use to check the validity of the certificate. Now, looking at all of these,
you might come to the conclusion that Firefox is doing a better job than anyone else here.
I happen to think that's correct. So my advice to people always is if security and privacy are
a concern use Firefox. There are probably some other things you might want to do but this is a
starting point. I would prefer Firefox to other browsers from the standpoint of security and privacy.
Another thing you can do enable whenever possible to factor authentication.
This prevents someone from using your password to log into your account since they would not
have the other factor. Google offers this for all of their accounts and the way it works is that
you get a text message on your phone with a six-digit number that you need to enter to complete the
login. I also obtained a free account from Duo Security recently which I used to secure my WordPress
websites. When I try to log into my site as an admin, I get a notification on my phone which I
need to respond to by authorizing the login. Personal accounts are free so check it out. There is
a link in the show notes. Now while we have some good advice from EFF on how you as an individual
can protect yourself, there is also a question of how we can improve the process and make it less
prone to failure. Here are the main ones being used so far. First in the area of certificate transparency.
Now I mentioned above Google has not done well with certificate revocation but that does not mean
it is ignoring the issue either. They have offered a proposal called certificate transparency.
As I understand it this is essentially a public log of all certificates issued and because
it is public it can be examined and monitored by anyone. For this to work your browser would need
to get a signed certificate timestamp SCT from this public log for any certificate that it wants to
receive. No SCT, no connection. So that is how you ensure that certificates are added to the log.
This solution relies on domain owners to monitor the log and look for anyone issuing false
certificates for their domains. Now clearly places like Google and Yahoo are doing that now and
that is how we have been catching some of these other problems that I noted above with bad
route certificate authorities issuing certificates. So certificate transparency is not a bad idea.
TLS extensions. TLS stands for transport layer security and it is the evolution of SSL.
Strictly speaking SSL has been deprecated and in fact SSL 3.0 there are actual exploits
in existence now that make it insecure and so what we are now seeing is browsers are implementing
code that will prevent a downgrade from TLS to SSL. So TLS is the wave of the future here and this
protocol has received numerous extensions over the years to do things like add new encryption
methods and extend the protocol in other directions such as renegotiation of connections.
So I think working within the TLS framework is certainly a good way to improve the process.
Finally I want to mention OCSP stapling. OCSP stands for the online certificate status protocol
and it is a way of verifying a certificate that relies on the issuing authority testifying that
the public key is still valid but it is still vulnerable to a man in the middle attack. OCSP
stapling solves these problems by having the certificate owner obtain the verification
from the certificate authority and then staple this to the certificate to a test to its validity.
This works by including a certificate status request in the TLS handshake
that tells your browser to look for the stapled certificate status from the certificate authority
if this is not found or is for some reason not valid. The browser should query the certificate
authority directly. The risk here is that if the certificate authority has been compromised
you can get a false response. So this is pretty good for dealing with hackers probably not enough
to deal with NSA and GCHQ. Now these process issues are the main problems with SSL certificates
and there is continued attention to improving the process. I don't know that there has to be one
and only one approach to improvement though. I would like to see Google use the revocation lists
while also promoting their transparency option and all of that can coexist quite nicely with TLS
extensions and OCSP stapling. So this wraps up our look at some of the issues with TLS certificates
and how we can resolve some of those issues and we'll be moving on to a different topic next time.
So this is Ahuka reminding everyone as always to support FreeSoftware. Bye bye.
You've been listening to HackerPublicRadio at HackerPublicRadio.org. We are a community podcast
network that releases shows every weekday Monday through Friday. Today's show, like all our
shows, was contributed by an HPR listener like yourself. If you ever thought of recording a
podcast then click on our contributing to find out how easy it really is. HackerPublicRadio was
founded by the digital dog pound and the infonomicum computer club and is part of the binary revolution
at binrev.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 create of comments, attribution, share a like, 3.0 license.