hpr-knowledge-base/hpr_transcripts/hpr0463.txt

Episode: 463
Title: HPR0463: Finux Interviews Moxie Marlinspike about SSL
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0463/hpr0463.mp3
Transcribed: 2025-10-07 21:09:47

---

...
...
Hello and welcome to Podcasts, it's still on the Hockey Public Radio episode, I'm your
host for today's show of Phoenix and I'm really lucky to be joined on the line today by
Moxie Marlon Spike. Hi Moxie, could you introduce yourself to the Hockey Public Radio audience please?
Hey, yeah, my name is Moxie Marlon Spike. I work at the Institute for Distrupted Studies
and I guess I'm going to be talking about SSL. As I say, I'm really tough that you've come on to
the call. For the guys that maybe haven't heard of you before, one of your projects, the tools
that you do is SSL Struck, could you maybe kind of give us a brief explanation of what SSL Strip
is for the HPR audience? Sure, the concept itself is pretty simple. The idea is basically that SSL
is pretty good, but how it's deployed really matters and on the web, SSL is deployed in this
kind of strange way where there's often a bridge between just HTTP and HTTPS and this bridge
is a very vulnerable point. Once you start looking at that, there's all kinds of tricks that you
can do to attack that bridge. As a SSL Strip, it's sort of a proof of concept. It's by default
implement the most straightforward attack, which is just preventing the connection from being
upgraded from HTTP to HTTPS. The evolution of the way the brothers have gone,
a reduction of positive feedback and a stronger introduction of negative feedback
help sort of enhance that attack, such that it's actually pretty deadly.
Yeah, I caught your Black Card DC talk over on securitytube.net and I really like the way that you'd
kind of use that bridge similarly for how HTTPS is used and I think that's really nice.
But I like the video, I think I always like seeing the practical demonstrations and I quite like
when you're showing that using SSL Strip, it's actually very hard for people to notice that
there might be on a site that's actually had all the SSL pulled out of it and it's relying on
a HTTP connection. I mean, you hear this band about a lot, but you get people say that,
oh really it's all about user education and user awareness and if they're looking for the
signs, they'll know that they're not on a secure site. Do you think that that's true or do you
think that really we need to take more ownership for actually maybe a little bit past user awareness?
Yeah, I don't think there's something else going on there more than just user awareness.
I gave that talk in DC and one of the most common reactions was, oh this is a matter of user
education, users are stupid and they just don't understand. We need to make them understand
the things that look for these indicators. And like I said, I think that there's something more
than that here, so that's sort of like a demonstration. I gave the same talk as Black Cat in Amsterdam
and like 10 minutes before my talk, I just ran at the SSL Strip on the network for 10 minutes and
I got like 50 passwords and I made a slide that was just a password, no use of names,
and so I just put all the password that I applied and I put a slide method as well, you know,
see the your passwords, right? Like even so-called security professionals are falling victim to
the attack and the idea is basically like if these people so-called security professionals
at a place like Black Cat, which is known to have a pretty hostile network, you know,
fall victim to the attack and what hope to 99% of users have, right? So I think there's something
else going on here and it's not just, you know, saying that user education has a problem.
Yeah, I mean, like you say, I mean, I saw the demonstration that you didn't on the video and,
you know, from here anyway, I thought it was actually very, very, very hard to tell the
difference between, you know, the secure, I think you use Gmail as an example in one of your slides
and, you know, you showed the secured version and the non-secured, well, that where the SSL
stripped out of it. And I mean, I found it very hard to actually tell in that. I think you kind of,
it was more about, you know, it seems to be that there's a push towards with browsers for this,
you know, negative reinforcement. Right, right, totally a lot of the positive indicators have
been sewn down and it varies from browser to browser, but I mean, especially if you look at
things like Safari, right, you know, the difference between a secured site into Safari and it's
straight to your pizza, it's just one little tiny blind-and-bought padlock in the upper right
corner and it's very small and that's the only thing that disappears. So, yeah, I think, you know,
most people's experiences to be browsing along and then, you know, continue normally until there's
something that appears as something drastically rather happened, you know. And so I think that's
the trend that browsers have been leading people and, you know, it's possible to exploit that trend,
using attacks like these. I mean, the other thing that I kind of wanted to talk to you about as well
is I also saw your, I also saw the video of your talk in Vegas and previous listeners to the show
will know, Chris John Riley and Frank Bradick actually mentioned your talk and your talk was
Nutrikes for Defeating Estes, was it Nutrikes for Defeating Estes, where you discussed, was it
in the no prefix attack? Right, right. Could you maybe kind of give us a brief description of
what that attack is, just for people on the HPR audience that might not have heard about it before?
Right. So this is, you know, this is a different attack. It's, and it uses, you know, I have two different
tools. One is as a self-strip, which is, you know, it does the stripping of attacking this sort of bridge,
and then I have this other tool as a self-sniff, which is designed more to attack the SSL connection
directly, whether on the web or anywhere else. And so this, this tool, the no prefix attacks are for
the idea is basically that, as self-certificates are based on the standard clinic 509, and
X5 and 9 represents data using ASN1, and substrings in the ASN1 form that are represented
as path-gal string, which means that there is a, you know, a length prefix, and then the string itself.
And this is in contrast to, you know, most of the cell augmentations, which are written in C,
and they use C strings, right, and C strings, you just get a pointer into the first character,
and your character string, and then, you know, whatever function that you're using continues
along the string until it encounters a null character, and then this is both indicated that you're
at the end of the string. So two different models of representing strings, and so what I've found
is that you can actually create strings in your certificates that have null characters in them.
And this is important because the way that certificate authorities have started to validate
identity is through the thing called domain validation, and the idea is basically you submit
a certificate signing request to certificate authority, and they look at the domain that you
want the certificate for, and they ignore everything except for the root domain. So I submitted
a certificate to give request for food.thoughtcrime.org, and they ignore everything but thoughtcrime.org,
and they do a, who is looked up, get my contact information out of the, who is database,
and contact me to verify that I am actually requesting certificate. So the interesting thing is,
I can get whatever I want, I can get food.thoughtcrime.org, I can get verifying each children that thought
crime.org I can get. So to give you the authority, there are total root.thoughtcrime.org, and you know,
whatever I submit the request for, they will ignore everything except for thoughtcrime.org,
and do the food.thoughtcrime.org. So as long as I control sort of the root domain,
I can get whatever I want. And what I found is that this includes things like dub, dub, dub,
dub, dub web, dub, dub, dub, dub, dub, dub, dub, dub, dub, dub, dub, dub, dub, dub, dub, dub, dub, dub, dub,
dub, dub, dub, dub, dub, dub, dub, dub, dub and dub.social.hasag can be your contact information.
client, or a VPN client, anything that uses SSL, it will pull out the name, it will pull
out the domain, and it will treat it as a C string, which means that when it goes to
compare it to whatever it was actually trying to connect to, so let's say it was trying
to connect to ptl.com, it will do a string compare between ptl.com and www.ppal.com, nocharacter.com.
That works. And the no character will terminate the string comparison such that it will think
that my certificate actually just says www.ppal.com. And the interesting thing is that it's
undetectable, right? There's no warnings and furthermore, once you go to inspect the certificate,
even then you don't see anything cut to the no character because even the functions that
are displaying the certificate information are, you know, tricked by the no character as well.
So it's a nice attack, it's pretty undetectable. The one variation was that I also found that,
you know, you can get wild cards certificates, right? So like I can get star.softcrime.org.
The deal is that then I get my one certificate and it will match www.crime.org,
mail.crime.org, you know, chat.crime.org, whatever I'd like. And I don't need a
difference certificate for each subdomain. And I found that the Mozilla,
as a cell of implementation, that the Mozilla products use, which is called NSF,
and actually a number of other pieces of software also use the same as the cell of
implementation, Pigeon, AIM, Evolution, a few others. This had a very strange way of
validating wild cards, such that I could get a certificate that said star, no character.softcrime.org.
And of course, when the implementation was presented with the certificate, it would evaluate to star.
And that would match any domain. So you could have this one certificate, star,
an old character.softcrime.org, and it would match anything that you compared it to.
And I called it a universal wild card certificate. It's sort of like having a C-Acer only,
it's actually better because if you have a C-Acer, you still have to create and sign the,
you know, leaf certificates that you'd like to, or if you have a universal wild card,
you just, you know, present the same thing over and over again and it matches everything.
So, I mean, you would deploy something, you know, you deploy your wild card, your universal
wild card. So you deploy that, say, on a man in the middle of the talk and on a company network.
What you're actually saying is, is that, you know, PayPal Gmail, whoever those
so secure sites they go to, they're actually using on the other end, even if they go to view the
certificate, or I should be told, they're viewing, like, if they're going to PayPal, that they're
actually seeing the PayPal certificate. Is that correct? So basically, you could pretty much own,
pretty much anyone's HTTPS sort of, you know, secure stuff on a, on networks then.
Sure, yeah. It plugs right into SSLsnet, which is, you know, the tool that I have. So,
you can actually just run SSLsnet on a network and you'll just get all of the SSL traffic.
And the touch of HTTPS is also all the other things that SSL is used for. It's, you know,
secure IMF, secure POP3, you know, secure IRC, SSL VPNs, really everything that SSL uses,
the SSL is used for. And, yeah, you just run SSLsnet and you get it all.
I mean, I've watched the video a couple of times ago. I just, I really loved the tour. I mean,
I thought it was fantastically done. I thought it was well presented and very, very interesting.
It made me, without sounding disrespectful and that's not what I'm meaning at all, but it
seemed to me that it was beautiful and it's simplicity, the null prefix attack, that, that,
you know, it was almost like the application process itself rather than the protocol itself.
Does that make sense? Oh, sure. I mean, this is an implementation of our ability, right?
You know, most vulnerabilities that you find are always software problems, you know.
It's rare that they're actual protocols on our abilities that are exploitable.
The thing that I think is interesting is when you manage to find implementation
vulnerabilities that span implementation, right? So this is a bug that's a problem with SSL
implementation, the bug in NSS. But the interesting thing is that almost everybody got it wrong. Almost
every SSL implementation that exists messes up, you know. And SSS is bad. The whole Microsoft
crypto API is bad. So every, every application that uses SSL on Microsoft will end up
as vulnerable to this. You know, the new TLS got it wrong. A lot of applications that use
SSL got it wrong. So I think that those are the kind of the most interesting things of,
not just when you find a bug in a piece of software, but you find a bug that everybody is stripped
over. Everything that personally tried to do this has all made the same mistake. I think those
are the really interesting implementation vulnerabilities. I mean, the other thing that I also
liked to touch on as well. It was also in that talk that you mentioned about the OCSP, the
online, basically the online certificate check in protocol, and how you'd actually overcome that.
I mean, would it be possible to get you to kind of like give us a brief description of what
OCSP is and actually how you defeat it? Right. So this is something that's like bordering on
a protocol vulnerability. And the deal is that OCSP is the online certificate status protocol.
You know, the idea is that the old mechanisms for revoking certificates are not really
working for people anymore. It used to be that if you revoke the certificate, it would just
get put in the certificate revocation list and every once in a while you would obtain the CRLs.
But now, you know, the problem is there's so many different certificates that each has their own
CRL and the lists are getting longer and longer. I mean, they're enormous now. It's really just
a nightmare to manage all of these things. So what people wanted instead was the protocol for
verifying certificates on the fly. And that's what OCSP is supposed to be doing, right? The idea is that
if you're a web browser or any SSL authentication, but let's just say a web browser,
he's a certificate for the first time. So, you know, you try to make a connection to
email and it gets the certificate for Google.com. And it says, while I haven't seen this yet,
it does a quick request to an OCSP URL embedded in the certificate. So the certificate has
inside of it embedded something that says OCSP check, you know, OCSP.com. And so it makes a quick
request out to OCSP.com. And it says, hey, is this certificate still okay? And you have to be
provider responds, either by saying, yeah, the certificate is fine. Or this is thing about.
And so if it's been revoked, then the web browser will pop up the dialogue or it will refuse
to accept the certificate. So the idea is that like if for some reason Google's certificate
is compromised or the certificate authority discovers that this was actually a forgery or
something like that, then they can very quickly revoke it and it won't even be worthless.
So this is something that's of interest to me, right? Because it's like, you know, I have all these
no prefix certificates. Well, what if somebody revokes them? And so I was looking at OCSP and
what's interesting is that it's not an SSL based protocol. And it's sort of obvious reasons, but
you know, you issue the OCSP request and you get an OCSP response back to the server.
And if the response is a successful response, if the response indicates that, you know,
that the certificate is okay, then it is signed by the OCSP provider. So it includes the
signature, which from our perspective might be difficult to forge. So what we would like to do
is send back, you know, what we'd like to do is intercept these requests, just like we're
intercepting the SSL connection. Call them in the middle of the pack and send back success,
but we can't do that very easily because, you know, we would have to include the signature.
So it turns out that there's a bunch of other response types that you can send.
And there's a class of response types that you can send that don't require any sign of data.
And because what's interesting is that the signature doesn't actually cover the response
type. It only covers some other things. So it turns out that you can actually send a response
that's the response type that's tri-later. And you don't have to sign that. So what you do is you send
back tri-later and a browser essentially treats that as a success. You know, it continues on
and presumably it will try again later than I can see as a certificate. But so if your certificate
has been revoked, then it doesn't get the revocation. So, you know, the kind of funny thing
was that the response code for tri-later is the character 3. And actually you don't have to include
any data other than that. So literally the only thing you respond with is the character 3,
like the fp0x33. And that's sort of defeats the whole protocol. OTSP is defeated by the number 3.
It seems like you have a heyday with SSL. I mean, what sort of got you into looking at SSL
and search? I mean, what kind of what kind of gets you going about that and why do you want to
kind of have a look at it and take it apart and see where it's got flaws in it. What sort of
inspires you to do that? Yeah. I mean, I guess a lot of my interest in computer security is
in the area of security protocols. Design security protocols, writing proofs for secure protocols
and so many secure protocols. And so, you know, I've been looking at SSL for a while, you know,
post another attack a long time ago. And the thing I like about SSL is just that it's kind of an
easy target because it's so universal, right? It's really everywhere and it's huge for other
types of things. So if you can find vulnerabilities in SSL or SSL implementation, you end up
getting a lot. You know, one one mistake can translate me to, you know, everybody is
pop 3-volgant in the world, you know. So it's kind of a nice thing to look at just because it's
so prevalent. I mean, I'm right in understanding that the that Firefox 3.5 and Firefox, I think
3 as well, have patched against the null prefix attack. Is that correct?
Yeah. The Firefox 3.5, Firefox 3.0.13 include patches for the null prefix vulnerability,
you know, the actually parts of the strings correctly and treat the null character as data that
should be compared. So those are fixed. I think there's probably, yeah, there's a new version
of the new TLS and I think there's some new, you know, people are slowly rebuilding their applications
and distributing new TLS. So people have been patching their applications against open SSL
and the, you know, strangely, the thing that remains unpatched is the entire Microsoft
crypto API. So basically anything on Windows is still vulnerable or prefix attack. And that
includes not just Internet Explorer and Outlook, but other browsers that run on Windows. So,
for instance, you know, Chrome on Windows is on the null prefix attack. The far beyond Windows is
vulnerable to a null prefix attack. Every thing that's on Windows right now is vulnerable.
So that's the big, that's the big gate left.
I could be wrong about this as well, but I think I thought I read somewhere as well that the Black
Bear's implementation is also susceptible to the attack as well. I think I read that last week
somewhere as well. So they're still quite a number of, quite a number of targets for this attack.
Yeah. I think the Black Bear folks really have to patch maybe this week.
And I think that, you know, we'll see stuff like that for a while. We'll see, you know,
random, as the final implementation here and there, we'll notice that we're vulnerable to this
and patching their stuff and releasing the code. And, yeah, you know, hopefully the
stuff will get distributed, kind of effectively, but it is a lot of, it's a lot to get back out there,
you know. Yeah, it sounds like, you know, there's, there's, I'm going to do some serious work to kind of
patch this, but is it right to say that the application process itself has still hasn't been
looked at that now? I mean, you know, you can still, you're able to use what you did to still get
wild cards. Oh, you mean from the terrific authorities? Yeah.
I think lots of those guys are probably fixed in their bugs. Yeah, I think lots of those guys
will probably not give you terrific appeal, no characters in them anymore.
I mean, it seems that, it seems that the logical stat and, and sort of this problem,
well, is to stop doing, doing, you know, making sure that they check for no characters within
sets. I mean, we surprised yourself when you actually put a little pressure on it, how,
how you didn't, you know, I imagine there was a lot of research that took place here for you
to, to find the no-reflex attack, but, you know, were you shocked to maybe how easily you took it apart?
No, I mean, there will always be software vulnerabilities. Yeah, this is not the, this is not the
last that's the cell vulnerability. You know, there's more stuff in there. It's, you know,
software will always be insecure. That's sort of the deal. So, yeah, for me, it's not,
it's not that surprising when you find the implementation vulnerabilities. You know,
finding critical level vulnerabilities, that's, that's a little bit more shocking. But,
the implementation stuff, it's just, you've just got to assume that it's all bad.
Okay, I'll, I'll not pick your brains any more about it, because I can just imagine over
the past, you know, a couple of weeks you've probably had to explain this attack to numbers of
people. It must be almost like, you know, coming, flowing off your tongue now, talking about
the null prefix attack. I, you know, I'm for anyone that doesn't know you, you're, you have a site
thoughtcrime.org, and I was having a look about, today I've had to look about a few times,
but I had it for the first time I actually had to look at your, your software section on your site.
And I actually surprised me how many tools you've actually got on there. I mean, what are some
of your favorite tools that you've got on there? I mean, I guess I like it all, right? But,
the, I mean, I just released a knock knock, which is a, a port knocker that I wrote, and I like
that, I mean, you know, most of the tools on everything that like, I wanted and couldn't find elsewhere.
And, you know, I think that people have been talking about port knocking for a long time,
and I was kind of surprised at how, how the, you know, how few good port knocking
implementations there are, you know, people have been sort of going crazy with these concepts,
and I feel like really deviating from the original intent behind it. And so I need to have
it to write my own port knocking implementation just because all of the out there seem so insufficient.
So, you know, I'm kind of excited about that knock knock. I think it's a pretty solid tool.
I use the Torotonal stuff a lot for creating a, turning it any tour exit node into a one-hot proxy.
I think that's pretty useful. Not for situations where you want like heavy levels of anonymity,
but perhaps you want some perspectives. You want to physically write your traffic through another
network segment so you get, you know, the perspective of looking at things from a different angle,
or if you just want, you know, some very minimal level of anonymity through a one-hot proxy.
And then, of course, you know, as it's self-strip and as it's self-strip, I think, you know,
useful for all different types of stuff. And those are probably the tools that I use the most.
So, Mark, see, how did you actually get into security? How did you get into this stuff then?
Through the, basically, like the 90s accuracy. You know, I don't, it's interesting. I don't know
what it looked like in your output in the United States. There was this sort of period during the 90s
where there was this kind of accuracy that was, you know, before the immersion of a professional,
like, computer security as an industry, right? So there was this kind of scene of people who were
interested and into computer security, not as a business, but as something that, you know,
they found inspiring and fun. And so, you know, I got into computer security through that sort of
theme before I turn into this more professional beyond. Okay. I mean, anyone that's
seen your site or will see that you have lots of side, you know, almost side projects and
all that sort of stuff going on. I thought it was quite interesting to see that you describe
yourself as, is it one part, sailor, one part, hacker, one part, pyro technician.
It made this mean that we've gone from hacking us ourselves to, you know, to basically delivering
yachts. It seems that you have quite, you know, quite a strange, you know, strange, but interesting
kind of setup going on. Yeah. I guess, I guess I do have some divergent interest, you know. So,
right, I'm really into sailing and part of this thing called the energy hot club. I have a
hundred ton master mariners license, and I use that to deliver yachts at time. And I mean,
it's making fireworks too. From scratch, you know, something that's pretty fun that I'm working on,
I think some folks where I live. So, yeah, I guess they're kind of divergent interest. And,
yeah, they don't, they don't overlap that much. I don't, you know, I'm into, like, the
sort of old school sailing techniques. I don't, like, combine technology with the ocean,
but yeah, I'm very kind of a weird tension in my life, so that's the deal.
I was to see that you did the hitchhiker's tour as well. That sounds, for me, in the UK,
that sounds like a really scary thing to do, but did you enjoy it or?
Yeah, I mean, I've spent a lot of time hitchhiking, riding freight trains, you know, traveling by
altering it with me. You know, a lot of the sailing that I've done has been fixing up derelict
loads and, you know, getting the floating again and, you know, sailing them out on the ocean. So,
yeah, I spent a lot of time traveling by altering it with me. I think hitchhiking used to be
something that was, you know, pretty exciting, and I think I learned a lot from riding trains
in the same way. So, yeah, I've got the story of the bell,
a strange ride, and some miserable moments, or whatever it was.
Moxie, another question that I have for you, buddy, is, are you speaking at any more conferences
this year or in near future? Yeah, let's see, I'm going to, I'm going to be visiting
at the University of Michigan, and I'm going to be on the 15th, no, this. And then I'm actually going
to hack that LU in Luxembourg at the end of October, and I might be going, I'm possibly giving
a, I have a training called Design and Secure Protocols and Recept and Secure Communication.
It's all about basically how to design a Secure Protocol, and using the knowledge of how to
design a Secure Protocol, evaluating Secure Protocols that already exist. So, I'm going to give
that training, I think, at deep sec that's in Vienna in November, and also at Black Hat in BC,
again, in, I guess it's the end of January and beginning of February. So, I think that's
the catch my travel roster. So, for people that want to kind of find out more about
your, what you're up to and that the projects that you're working on, do you have a blog that people
can follow? No, I just, I post stories on TalkR.org, and yeah, I mean, that's probably the best
places, you know, so it's me, software, and some stories up there, and that's probably the best
place for, and white papers, I guess, whatever it is. Yeah, I mean, I've been, I've been on the site,
and I definitely recommend that people go and have a look, it's absolutely awesome.
The interest of not taking up any more of your time, I'll wrap up with the, with the interview,
is there anything in particular that you want to speak about, or talk about, to that hack
public radio audience?
No, I think, I think we've covered it, you know, this is just sort of like, I guess, the overview
of all this SSL stuff, and if people are interested, they can read the white papers for a little
bit more information, and check out the software, and look at the source and stuff for figuring
out how all this stuff really works. And, you know, feel free to email me and correspond and stuff
like that. So, basically, don't trust SSL.
Yeah, well, I mean, it's, you know, don't trust software, I guess that's the real room I've
been trying to say. It's, you know, people have been working on this for a long time, and,
you know, if you look at projects, like, open up the page, you know, these,
something like open up the page has been designed from the ground up for security.
Every single line of code that is written on that project is done with security in mind.
People are constantly auditing, you know, very paranoid group of people who are writing this,
and yet, there's still software vulnerabilities that can be released. And I think, you know,
we have to acknowledge that if that is true, you know, what hope do we have of finding security
in all the other products that weren't level. We weren't working with that level of security in
mind. And so, you know, the lesson is that software is insecure, and always we need to plan
accordingly and take other steps for feeling a bit.
Brilliant. Like I say, I mean, you can find Monksys at thoughtcrime.org, and it's definitely
well worth a visit. Monksys, I'd like to thank you for coming on the line and allowing me to
ask, I see these questions. It's very nice of you, and I hope that the Hacker Public Radio
audience will enjoy it. So, all that's really left for me to do is thank Monksy and thank the
Hacker Public Radio audience for listening. Before I go, if anyone from the Hacker Public Radio
audience wants to get involved in podcasting, they can always record an episode on anything that
they're interested in. Maybe there's someone want they want to interview or a project they want
to talk about or how to guide or something like that. You can record a show, and if you contact
either Clature or Nick Merritt at HackerPublicRadio.org, they can help to get the show out for you.
So, once again, thank you all, and I'll catch you next time on Hacker Public Radio.
Thank you for listening to Hacker Public Radio. HPR is sponsored by Kero.net, so head on over to
clro.int. for all of us here.