Patrick W. Gilmore wrote:
Anyone have a foolproof way to get grandma to always put https://; in
front of www?
I understand this is a huge can of worms, but maybe it's time to change the
default behavior of browsers from http to https...?
I'm sure it's doable in FF with a simple plugin, one
On Thu, 24 Jul 2008 09:51:40 +0200
Robert Kisteleki [EMAIL PROTECTED] wrote:
Patrick W. Gilmore wrote:
Anyone have a foolproof way to get grandma to always put https://;
in front of www?
I understand this is a huge can of worms, but maybe it's time to
change the default behavior of
On Thu, 2008-07-24 at 09:51 +0200, Robert Kisteleki wrote:
Patrick W. Gilmore wrote:
Anyone have a foolproof way to get grandma to always put https://; in
front of www?
I understand this is a huge can of worms, but maybe it's time to change the
default behavior of browsers from http to
On Thu, 2008-07-24 at 09:51 +0200, Robert Kisteleki wrote:
Patrick W. Gilmore wrote:
Anyone have a foolproof way to get grandma to always put https://; in
front of www?
I understand this is a huge can of worms, but maybe it's time to change the
default behavior of browsers from http to
On Thursday 24 July 2008 05:17:59 Paul Ferguson wrote:
Let's hope some very large service providers get their act together
real soon now.
http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html
It isn't going to happen without BIG political pressure, either from users, or
On Wed, Jul 23, 2008 at 9:44 PM, Joe Greco [EMAIL PROTECTED] wrote:
Except this time your reply comes with an additional record
containing the IP for www.gmail.com to the one you want to redirect it
to.
Thought that was the normal technique for cache poisoning. I'm pretty
sure that
On Wed, 23 Jul 2008, Kevin Day wrote:
The new way is slightly more sneaky. You get the victim to try to
resolve an otherwise invalid and uncached hostname like 1.gmail.com,
and try to beat the real response with spoofed replies. Except this time
your reply comes with an additional record
If you can reply to me with the ticket details and number I can make
sure it get looked at by the right folks.
Regards,
Eric J. Mort
Sr. Manager - IP Operations
Desk - 314-787-7826
Cell - 314-486-9057
[EMAIL PROTECTED]
-Original Message-
From: William R. Lorenz [mailto:[EMAIL
Is anyone using Vyatta for routing? I sure would like to know about any
experience with it in production.
http://www.vyatta.com/
--
Tim Sanderson, network administrator
[EMAIL PROTECTED]
-Original Message-
From: randal k [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 23, 2008 1:46 PM
downplay this all you want, we can infect a name server in 11 seconds now,
which was never true before. i've been tracking this area since 1995. don't
try to tell me, or anybody, that dan's work isn't absolutely groundbreaking.
i am sick and bloody tired of hearing from the people who
On Thu, 24 Jul 2008 10:06:25 +0100
Simon Waters [EMAIL PROTECTED] wrote:
I checked last night, and noticed TLD servers for .VA and .MUSEUM are
still offering recursion amongst a load of less popular top level
domains.
Indeed just under 10% of the authoritative name servers mentioned in
the
Sure, I can empathize, to a certain extent. But this issue has
been known for 2+ weeks now.
Well we knew about the DNS issues since long time ago (20+yrs perhaps?),
so the issue is not new, just the exploit is more easy to put together and
chances for it to succeed are much higher.
As I
i am sick and bloody tired of hearing from the people who aren't impressed.
Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is
groundbreaking, except that threats discussed long ago have become more
practical due to the growth of network and processing speeds, which was
So, look at other options:
* Widen the query space by using multiple IP addresses as
source. This,
of course, has all the problems with NAT gw's that the port solution
did, except worse.
This makes using your ISP's properly designed resolver even more
attractive,
Somewhere I've seen what amounts to a concave cover that you can mount
over the face of gear racked in a 2-post. The cover I saw had a bracket
that mounted to the 2-post before any equipment was installed and it had
a couple knobs sticking out (basically consuming a U on each end). Then
you
i am sick and bloody tired of hearing from the people who aren't
impressed.
Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is
groundbreaking, except that threats discussed long ago have become more
practical due to the growth of network and processing speeds,
On Thu, 24 Jul 2008, Paul Ferguson wrote:
Let's hope some very large service providers get their act together
real soon now.
There is always a tension between discovery, changing, testing and
finally deployment.
Sure, I can empathize, to a certain extent. But this issue has
been known for
On Thu, 24 Jul 2008 09:10:13 -0500
Jorge Amodio [EMAIL PROTECTED] wrote:
Sure, I can empathize, to a certain extent. But this issue has
been known for 2+ weeks now.
Well we knew about the DNS issues since long time ago (20+yrs
perhaps?), so the issue is not new, just the exploit is
On Jul 24, 2008, at 9:22 AM, Paul Vixie wrote:
11 seconds.
and att refuses to patch.
and all iphones use those name servers.
This caught my attention, and so I tossed the ATT wireless card in my
laptop and ran the test:
[rogue:~] steve% dig +short porttest.dns-oarc.net TXT
Robert Kisteleki wrote:
Patrick W. Gilmore wrote:
Anyone have a foolproof way to get grandma to always put https://; in
front of www?
I understand this is a huge can of worms, but maybe it's time to change
the default behavior of browsers from http to https...?
I'm sure it's doable in FF
So, look at other options:
* Widen the query space by using multiple IP addresses as
source. This,
of course, has all the problems with NAT gw's that the port solution
did, except worse.
This makes using your ISP's properly designed resolver even more
attractive, rather than
On 24 Jul 2008, at 10:56, Joe Greco wrote:
MY move? Fine. You asked for it. Had I your clout, I would have
used
this opportunity to convince all these new agencies that the
security of
the Internet was at risk, and that getting past the who holds the
keys
for the root zone should be
On Thu, 24 Jul 2008, Joe Greco wrote:
downplay this all you want, we can infect a name server in 11 seconds now,
which was never true before. i've been tracking this area since 1995. don't
try to tell me, or anybody, that dan's work isn't absolutely groundbreaking.
i am sick and bloody tired
On Thu, 24 Jul 2008, Paul Vixie wrote:
11 seconds.
and att refuses to patch.
and all iphones use those name servers.
Has att told you they are refusing to patch? Or are you just spreading
FUD about att and don't actually have any information about their plans?
On Thu, 24 Jul 2008, John Kristoff wrote:
On Thu, 24 Jul 2008 10:06:25 +0100
Simon Waters [EMAIL PROTECTED] wrote:
I checked last night, and noticed TLD servers for .VA and .MUSEUM are
still offering recursion amongst a load of less popular top level
domains.
Indeed just under 10% of the
On Thu, 24 Jul 2008, Gadi Evron wrote:
But sticking to the point, TLD servers should (under most circumstances) be
Should NEVER, oops.
On Thu, 2008-07-24 at 11:21 -0400, Sean Donelan wrote:
On Thu, 24 Jul 2008, Paul Vixie wrote:
11 seconds.
and att refuses to patch.
and all iphones use those name servers.
Has att told you they are refusing to patch? Or are you just spreading
FUD about att and don't actually have
On 24 Jul 2008, at 10:56, Joe Greco wrote:
MY move? Fine. You asked for it. Had I your clout, I would have
used
this opportunity to convince all these new agencies that the
security of
the Internet was at risk, and that getting past the who holds the
keys
for the root
On Thu, Jul 24, 2008 at 9:35 AM, Joe Greco [EMAIL PROTECTED] wrote:
Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is
groundbreaking, except that threats discussed long ago have become more
practical due to the growth of network and processing speeds, which was
a hazard
On Thu, 24 Jul 2008, Martin Hannigan wrote:
I personally know several folks from within and wayyy from outside the
DNS
world who discovered this very out there and obvious issue and worked
hard
to try and contact the operators. Those that haven't fixed it yet,
likely
won't if all thing
11 seconds.
and att refuses to patch.
and all iphones use those name servers.
Has att told you they are refusing to patch? Or are you just spreading
FUD about att and don't actually have any information about their plans?
I believe it is a hypothetical situation being
On 24 Jul 2008, at 11:40, Joe Greco wrote:
Compared with the problem of global DNSSEC deployment, getting
everybody in the world to patch their resolvers looks easy.
Of course. That's why I said that deploying this patch was
something that
could be done *too*.
OK, good. Sorry if I
On Thu, 24 Jul 2008 15:50:15 -
Martin Hannigan [EMAIL PROTECTED] wrote:
I don't know that a failure to act immediately is indicative of
ignoring the problem. Not to defend ATT or any other provider, but
it's not as simple as rolling out a patch.
Right. What scares me is all of the
just posted on bugtraq and uk newsgroups
Original Message
Subject: CAU-EX-2008-0002: Kaminsky DNS Cache Poisoning Flaw Exploit
Date: Wed, 23 Jul 2008 18:34:26 -0500
From: I)ruid [EMAIL PROTECTED]
Organization: Computer Academic Underground
To: [EMAIL PROTECTED]
CC: bugtraq
[EMAIL PROTECTED] (Jorge Amodio) writes:
As I mentioned in another message, perhaps its time to get serious about
DNSSEC, where are we on this front ?
still waiting for US-DoC to give ICANN permission to sign the root zone.
--
Paul Vixie
--
This message has been scanned for viruses and
[EMAIL PROTECTED] (Jorge Amodio) writes:
As I mentioned in another message, perhaps its time to get serious about
DNSSEC, where are we on this front ?
Still waiting for US-DoC to give ICANN/IANA permission to sign the root zone.
--
Paul Vixie
--
This message has been scanned for viruses and
[EMAIL PROTECTED] (Phil Regnauld) writes:
Case in point, we've got customers running around in circles
screaming we need to upgrade, please help us upgrade NOW,
but they have _3_ layers of routers and firewalls that are hardcoded to
only allow DNS queries from port 53.
[EMAIL PROTECTED] (Simon Waters) writes:
The advice NOT to allow recursion on TLD servers is well over a decade old.
it's not just advice, really. on the mailing list that's a little like this
one except that unlike this one it's meant for DNS operations issues, i said
Jorge Amodio wrote:
/etc/hosts rulez !!! :-)
Wonder if SRI wstill has the files.
--
Requiescas in pace o email Two identifying characteristics
of System Administrators:
Ex turpi causa non oritur actioInfallibility, and the
/etc/hosts rulez !!! :-)
Wonder if SRI wstill has the files.
The SRI-NIC is long gone, I still remember the IP address
of the ftp server 10.0.0.51 :-)
There are several historic copies all over the net.
Jorge
On Thu, 24 Jul 2008, Paul Vixie wrote:
ATT Response: US-CERT DNS Security Alert- announced July 8, 2008
2008. The latest patch for alert TA08-190B is currently being tested and
will be deployed in the network as soon as its quality has been assured.
That doesn't sound like refuses to patch.
Jorge Amodio wrote:
/etc/hosts rulez !!! :-)
Wonder if SRI wstill has the files.
Using the methods in RFC-952 and RFC-953 I wasn't able
to get them. I can't find if there is an updated RFC/name to use.
Tuc/TBOH ;)
-Original Message-
From: Gadi Evron [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24, 2008 11:52 AM
To: Martin Hannigan
Cc: nanog@nanog.org
Subject: RE: TLD servers with recursion was Re: Exploit for DNS
CachePoisoning- RELEASED
On Thu, 24 Jul 2008, Martin Hannigan wrote:
Refuses to patch sounds likes FUD.
go ask 'em, and let us all know what they say.
kaminsky tried to get everybody a month, but because of ptacek's sloppiness
it ended up being 13 days. if any dns engineer at any internet carrier goes
home to sleep or see their families before they patch, then
On Thu, Jul 24, 2008 at 09:56:32AM -0500, Joe Greco wrote:
MY move? Fine. You asked for it. Had I your clout, I would have used
this opportunity to convince all these new agencies that the security of
the Internet was at risk, and that getting past the who holds the keys
for the root zone
He,he,nice comment. The issue is that with todays html crap and embedded
images on mails click is no longer required, just include a malicious tag
forcing your resolver to go to bad boy's NS to resolve the URL and you are
up in biz.
Can't stop laughing ... its a rainy boring day in south
Hi,
Not sure if anyone has seen yet, but there is a 2nd
exploit being circulated. I just picked it up on metasploits
SVN trunk
The first was called baliwicked_host, and the
description was :
This exploit attacks a fairly ubiquitous flaw in DNS implementations which
Dan
On Thu, 24 Jul 2008, Paul Vixie wrote:
Refuses to patch sounds likes FUD.
go ask 'em, and let us all know what they say.
I believe att has already said they are testing the patch and will deploy
it as soon as their testing is completed. Other than you, I have not
heard anyone in att say
Is it just me or is the test page below down now?
Or maybe some poisoned the NS record for dns-oarc.net and sent it to
nowhere to stop testing! (J/K since I can get to the rest of the page
fine).
-Scott
-Original Message-
From: Ken A [mailto:[EMAIL PROTECTED]
Sent: Thursday,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -- Tuc at T-B-O-H.NET [EMAIL PROTECTED] wrote:
Not sure if anyone has seen yet, but there is a 2nd
exploit being circulated. I just picked it up on metasploits
SVN trunk
I haven't seen that one yet, but I just ran across this:
/lurk
I apologize for neglecting to mention the excellent test labs I've worked
with in Europe, including EANTC (in Germany) and West Coast Labs (in Wales,
I believe). Both are highly reputable and have access to lots of test
equipment (and they know how to use it!).
lurk
On Mon, Jul 21,
On Thu, 24 Jul 2008, Paul Vixie wrote:
I believe att has already said they are testing the patch and will deploy
it as soon as their testing is completed. Other than you, I have not
heard anyone in att say they are refusing to patch.
i read att write that this was a rehash of a previously
Some broadband providers here in .br seems to be blocking access to
the dns-oarc.net test zone (but not to the portal site); most thought
it was intended behavior by those providers (hiding instead of
patching), but you are right, someone might have corrupted the test
zone itself, which aleviates
Tuc at T-B-O-H.NET wrote:
The new one is called baliwicked_domain and its described
as :
This exploit attacks a fairly ubiquitous flaw in DNS implementations which
Dan Kaminsky found and disclosed ~Jul 2008. This exploit replaces the target
domains nameserver entries in a vulnerable
Here's some older ones:
http://pdp-10.trailing-edge.com/cgi-bin/searchbyname?name=hosts.txt
Prior to departing SRI last year I spent a bunch of time trying to find some of
the old SRI-NIC records. It appears that they were all cleaned out once the
contract was closed and the Internet was
On Jul 24, 2008, at 10:17 AM, Duane Wessels wrote:
Give this one a try:
http://entropy.dns-oarc.net/test/
For one iPhone it reported 209.183.54.151 as having GREAT source port
randomness and GREAT transaction ID randomness. However, despite the
test reporting GREAT, the source ports
For one iPhone it reported 209.183.54.151 as having GREAT source port
randomness and GREAT transaction ID randomness. However, despite the
test reporting GREAT, the source ports were _definitely_ non-random.
http://5d93b9656563a44e4c900ff9.et.dns-oarc.net/
Proving random is not easy.
On Thu, Jul 24, 2008 at 1:14 PM, Paul Vixie [EMAIL PROTECTED] wrote:
in spite of that caution i am telling you all, patch, and patch now. if you
have firewall or NAT configs that prevent it, then redo your topology -- NOW.
and make sure your NAT isn't derandomizing your port numbers on the way
Neil Suryakant Patel is the nominee for AS for Communications and
Information at DoC. If he's in the loop, even advisory pending ...,
and as a Cheney staffer (intially staff secretary, now as a domestic and
economic policy adviser), that's possible, then adjust expectations
accordingly.
Paul
On Thu, Jul 24, 2008 at 1:14 PM, Paul Vixie [EMAIL PROTECTED] wrote:
and if you have time after that, write a letter to your congressman about the
importance of DNSSEC, which sucks green weenies, and is a decade late, and
which has no business model, but which the internet absolutely dearly
So is this patch a true fix or just a temporary fix until further
work can be done on the problem?
the only true fix is DNSSEC. meanwhile we'll do UDP port randomization,
plus we'll randomize the 0x20 bits in QNAMEs, plus we'll all do what
nominum does and retry with TCP if there's a QID
The problem is, once the ICANNt root is self-signed, the hope of ever
revoking that dysfunctional mess as authority is gone.
Perhaps the IETF or DoC should sign the root, that way we have a prayer
of wresting control from ICANN, as opposed to paying a tax, in
perpetuity, for registration services
On Thu, Jul 24, 2008 at 3:05 AM, Steven M. Bellovin [EMAIL PROTECTED] wrote:
The round trip issue affects latency, which in turn affects perceived
responsiveness. This is quite definitely the reason why gmail doesn't
always use https (though it, unlike some other web sites, doesn't
refuse to
On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote:
The problem is, once the ICANNt root is self-signed, the hope of ever
revoking that dysfunctional mess as authority is gone.
Sorry, I don't follow -- sounds like FUD to me. Care to explain this?
As far as I'm aware, as long as the KSK isn't
On Thu, 24 Jul 2008 17:43:10 PDT, David Conrad said:
On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote:
The problem is, once the ICANNt root is self-signed, the hope of ever
revoking that dysfunctional mess as authority is gone.
As far as I'm aware, as long as the KSK isn't compromised,
On Thu, 24 Jul 2008, Steve Bertrand wrote:
Gadi Evron wrote:
On Thu, 24 Jul 2008, Martin Hannigan wrote:
I personally know several folks from within and wayyy from outside the
DNS
world who discovered this very out there and obvious issue and worked
hard
to try and contact the operators.
Tomas L. Byrnes [EMAIL PROTECTED] wrote:
The problem is, once the ICANNt root is self-signed, the hope of ever
revoking that dysfunctional mess as authority is gone.
that sounds like the kind of foot-dragging that could be holding this up.
Perhaps the IETF or DoC should sign the root, that
On Thu, 24 Jul 2008, Jeffrey Ollie wrote:
Interestingly enough, Google just added a feature to GMail to force
secure connections:
http://googlesystem.blogspot.com/2008/07/force-gmail-to-use-secure-connection.html
Jeff
I wish Yahoo and Hotmail even had the ability of *reading* email via
On Thu, Jul 24, 2008 at 10:32 AM, Tuc at T-B-O-H.NET [EMAIL PROTECTED] wrote:
- -- Robert D. Scott [EMAIL PROTECTED] wrote:
Now, there is an exploit for it.
http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
Now also (mirrored) here:
http://www.milw0rm.com/exploits/6122
On Thu, Jul 24, 2008 at 10:32 AM, Tuc at T-B-O-H.NET [EMAIL PROTECTED]
wrote:
- -- Robert D. Scott [EMAIL PROTECTED] wrote:
Now, there is an exploit for it.
http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
Now also (mirrored) here:
On Thu, Jul 24, 2008 at 11:24 PM, Hank Nussbacher [EMAIL PROTECTED] wrote:
I wish Yahoo and Hotmail even had the ability of *reading* email via https:
http://www.interall.co.il/hotmail-yahoo-https.html
Hah! It was only a year ago that Yahoo even added SSL capabilities
for login. Six months
71 matches
Mail list logo
