Re: Somewhat off-topic: comp-arch.net cloned, possibly hacked




"Andy \"Krazy\" Glew" <andy@xxxxxxxxxxxxxxxxxx> writes:
I find it interesting that DNS does not have a mechanism to ensure
that domains and IP addresses are consistent. E.g. a digital
signature/hash including both, made with a private key corresponding
to a public key posted in whois.

one of the domain name infrastrucutre vulnerabilities is domain name
hijacking,

part of DNSSEC was registering a public key at the some time the domain
name registration was done. then all future communication between the
domain name owner and the domain name infrastructure is digially signed
with the own-file pubic key ... several instances of domain name
hijacking where impersonator fraudulent convinces the domain name
infrastructure to update the domain name inframation.

Then the fraudulent domain name owner can apply to the SSL domain name
issuer for a valid SSL digital certification ... providing valid
information that corresponds with the information on file at the domain
name infrastructure.

To some extent the SSL domain name vendors were supporting such DNSSEC
operation with pre-registered, onfile public key. Part of the issue is
that they currently use an error-prone, expensive, and time-consuming
identification process that attempts to match the information supplied
on the SSL domain name digital certificate application with the
information on-file at the domain name infrastructure.

With on-file, registered public keys at the domain name infrastructure,
the SSL domain name infrastructure can start reguiring that SSL domain
name certificate application be digitally signed. Then the SSL digital
certificate vendor can retrieve the on-file public key from the domain
name infrastructure to verify the signature on the SSL domain name
certificate application. note that this creates something of catch-22
for the SSL digital certificate vendors since if they could do real-time
retrieval of on-file public keys from the domain name infrastructure,
then could the rest of the world (obsoleting need for SSL digital
certificates for distribution of public keys) ... misc. past posts
http://www.garlic.com/~lynn/subpubkey.html#catch22

I've suggested a much more efficient and revised SSL handshake where
onfile public key could be piggy-backed in standard DNS response ... and
then used to encrypt the generated session secret key which is sent
during initial connection.

for other drift ... from today, fraudulent digital certificate:

Fraudulent Google credential found in the wild
http://www.theregister.co.uk/2011/08/29/fraudulent_google_ssl_certificate/
Hackers acquire Google certificate, could hijack Gmail accounts
http://www.computerworld.com/s/article/9219569/Hackers_acquire_Google_certificate_could_hijack_Gmail_accounts

--
virtualization experience starting Jan1968, online at home since Mar1970
.