Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- X.509 weakness?
June 16, 2007, 3:32 pm
rate this thread
When I connect to a server using ssh the first time, I get a message
if I really want to connect to this guy.
I replace a server and recycle its IP address, ssh does not want me
connect as the certificate has changed.
So is this a weakness? Say I connect to a server, accept its
certificate and am happy.
Bad guy Garth also snags a copy of the certificate.
The next time I connect to the server, bad guy Garth has changed my
DNS so that
instead of going to the correct server, I go to bad guy Garth's server
who is pretending
to be my server. I look at the CN=www.freesoft.org and say, wow
server I want and the certificate is good. I am happy.
Am I missing something? Is it possible, by manipulating a DNS server
for a bad
guy to server up a good certificate and have it be undetected by a
Re: X.509 weakness?
SSL tends to have other sorts of (possibly process) weaknesses.
some old posts about being called into work work with this small
client/server startup that wanted to do payments on their server
and they had this technology they called SSL ... and needed
to work out and validate all the business processes
the original design point was that the person typed in the URL ... and
then the server provided a ssl domain name certificate that the browser
compared the domain name in the certificate against the domain name in
the typed in URL. This allowed that the server that the person thot they
were talking to was the server that they were talking to ... aka the
person knew the connection between the server they wanted to talk to and
the server's URL ... the browser/SSL part provided the connection
between the URL and the server.
However, relatively early, merchants found that SSL degraded their
webserver thruput by something like 90% ... so SSL was quickly
restricted to just the check-out/payment portion. Now, the user goes to
a website (that isn't validated with SSL) and eventually clicks on a
button that generates a URL for a payment website ... which is
cross-checked against some SSL certificate. Since a potential attacker
now may be providing both the URL and the certificates ... and the user
has lost all association between the website they think they are talking
and the corresponding URL ... the SSL check no longer means a whole lot
(for just about all uses of SSL in the world today). This is the basis
of a lot of phishing and other kinds of attacks ... providing a field
for the user to click on ... that may claim one thing ... but the actual
URL can be totally unrelated to what is being claimed. Then the SSL
operation is only checking that the URL (possibly provided by an
attacker) matches the certificate (also provided by the attacker).
So, at least part of the original motivation for SSL was countermeasure
to some perceived weakenesses in the domain name infrastructure.
However, most certification authorities (that issue SSL digital
certificates) aren't the authoritative agency for the information they
are certifying. The authoritative agency is the domain name
infrastructure. A certification authority asks for a whole bunch of
identification as part of the application. Then an attempt is made to do
the expensive, error-prone, and time-consuming operation of matching the
supplied identification information with the identification information
on file with the domain name infrastructure (as to the owner of the
So, somewhat backed by the certification authority industry ... there
are some activities to improve the integrity of the domain name
infrastructure. However, this represents a catch-22 for the industry
improving the integrity of the domain name infrastructure weakens the
original justification for having ssl domain name certificates.
Another catch-22 is some of the improvements in integrity involve
domain name owners putting public keys on file with the domain
name infrastructure ... then all future communication is digitally
signed ... and then there is a (certificateless) verification of
the digital signature with the onfile public key
The issue here is that the certification authorities then could also
start requiring SSL digital certificate applications also be digitally
signed. Then they could switch from an expensive, time-consuming,
error-prone identification process to a much more reliable, simpler, and
less-expensive authentication process ... by doing real-time retrieval
of the onfile public key to do a (certificateless) verification of the
applicants digital signature.
The further catch-22 is that if the certification authorities could
start doing real-time (certificateless) public key operations ... then
possibly the rest of the world would also start doing real-time
certificateless public key operations also (eliminating all requirement
for having the redundant and superfluous ssl digital certificate).
One might even managed a super optimized, highly efficient variation,
where the appropriate public key was piggy-backed on standard DNS
response (in a single operation, possibly along with some crypto
options). The client then generates a session key, encrypts the initial
transmission, and then encrypts the session key with the servers public
key. Then the stuff is sent in one transmission to the server. Only the
correct server would be able to decrypt the session key. However, except
for possibly small increase in payload size ... all the additional
crypto-specific protocol chatter and transmission overhead has been
- Richard E. Silverman
June 16, 2007, 10:00 pm
Re: X.509 weakness?
bsd> When I connect to a server using ssh the first time, I get a
bsd> message asking if I really want to connect to this guy.
bsd> I replace a server and recycle its IP address, ssh does not want
bsd> me connect as the certificate has changed.
bsd> So is this a weakness? Say I connect to a server, accept its
bsd> certificate and am happy. Bad guy Garth also snags a copy of the
bsd> The next time I connect to the server, bad guy Garth has changed
bsd> my DNS so that instead of going to the correct server, I go to
bsd> bad guy Garth's server who is pretending to be my server. I look
bsd> at the CN=www.freesoft.org and say, wow thats the server I want
bsd> and the certificate is good. I am happy.
If you're actually using X.509 certificates, the idea is that this should
not happen. You will only say the certificate is "good" if it's signed by
a CA that you trust, and such a CA should not issue a certificate for
www.freesoft.org to anyone but the legitimate owner of that domain.
Note that although there are SSH implementations which use certificates,
you're probably not using one. If you're using stock OpenSSH, there are
no X.509 certificates, just public keys bound to names in your known_hosts
file. In this case, *you* are responsible for verifying the name/key
association on the first connection (e.g. by obtaining the fingerprint
from a trusted source).
bsd> Am I missing something? Is it possible, by manipulating a DNS
bsd> server for a bad guy to server up a good certificate and have it
bsd> be undetected by a client?
Re: X.509 weakness?
All true (of course), but I think you missed the "snags" part. To the
OP: The bad guy can snag certificates and SSH public keys all he wants,
that's part of their being "public" after all, but that doesn't allow
him to pretend to be anyone. In both cases the proof of identity lies
with the possession of the *private key*, which can't be snagged by
other means than breaking into the real server with the privileges
needed to get at the key, if the owner is taking proper care of it.
During authentication, the server is required to demonstrate that he has
the private key that corresponds to the public one, and a bad guy that
doesn't have the private key will not be able to do that.
- » Looking for Subversion server-side SSH key manager
- — Previous thread in » Secure Shell Forum
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — Newest thread in » Secure Shell Forum