In message <4962e096.7070...@karnaugh.za.net>, Colin Alston writes:
> On 2009/01/05 10:47 PM Randy Bush wrote:
> > perhaps i am a bit slow. but could someone explain to me how trust in
> > dns data transfers to trust in an http partner and other uses to which
> > ssl is put?
>
> I must also be
On 2009/01/05 10:47 PM Randy Bush wrote:
perhaps i am a bit slow. but could someone explain to me how trust in
dns data transfers to trust in an http partner and other uses to which
ssl is put?
I must also be slow. Can someone tell me how DNSSEC is supposed to
encrypt my TCP/IP traffic?
In message <20090105201859.gc15...@ferrum.uhlenkott.net>, Jason Uhlenkott write
s:
> On Fri, Jan 02, 2009 at 15:33:05 -0600, Joe Greco wrote:
> > This would seem to point out some critical shortcomings in the current SSL
> > system; these shortcomings are not necessarily technological, but rather
On Tue, Jan 06, 2009 at 06:09:34 +0900, Randy Bush wrote:
> to use your example, the contractor who serves dns for www.bank.example
> could insert a cert and then fake the web site having (a child of) that
> cert. whereas, if the site had its cert a descendant of the ca for all
> banks, this at
On 01/05/09 12:47, Randy Bush wrote:
> perhaps i am a bit slow. but could someone explain to me how trust in
> dns data transfers to trust in an http partner and other uses to which
> ssl is put?
Because I have to trust the DNS anyway. If the DNS redirects my users
to a bad site, they may not no
Randy Bush wrote:
perhaps i am a bit slow. but could someone explain to me how trust in
dns data transfers to trust in an http partner and other uses to which
ssl is put?
randy
It wouldn't, which is why the original suggestion is a bad idea.
They're different issues (finding the actual ad
> On 09.01.06 05:59, Joe Abley wrote:
> >> perhaps i am a bit slow. but could someone explain to me how trust in
> >> dns data transfers to trust in an http partner and other uses to which
> >> ssl is put?
> >
> > If I can get secure answers to "www.bank.example IN CERT?" and
> > "www.bank.example
On Tue, 06 Jan 2009 06:09:34 +0900, Randy Bush said:
> to use your example, the contractor who serves dns for www.bank.example
> could insert a cert and then fake the web site having (a child of) that
> cert. whereas, if the site had its cert a descendant of the ca for all
> banks, this attack
On 09.01.06 05:59, Joe Abley wrote:
perhaps i am a bit slow. but could someone explain to me how trust in
dns data transfers to trust in an http partner and other uses to which
ssl is put?
If I can get secure answers to "www.bank.example IN CERT?" and
"www.bank.example IN A?" then perhaps when
On 2009-01-05, at 15:47, Randy Bush wrote:
perhaps i am a bit slow. but could someone explain to me how trust
in dns data transfers to trust in an http partner and other uses to
which ssl is put?
If I can get secure answers to "www.bank.example IN CERT?" and "www.bank.example
IN A?" the
perhaps i am a bit slow. but could someone explain to me how trust in
dns data transfers to trust in an http partner and other uses to which
ssl is put?
randy
On 2009-01-05, at 15:18, Jason Uhlenkott wrote:
If we had DNSSEC, we could do away with SSL CAs entirely. The owner
of each domain or host could publish a self-signed cert in a TXT RR,
... or even in a CERT RR, as I heard various clever people talking
about in some virtual hallway the othe
On Fri, Jan 02, 2009 at 15:33:05 -0600, Joe Greco wrote:
> This would seem to point out some critical shortcomings in the current SSL
> system; these shortcomings are not necessarily technological, but rather
> social/psychological. We need the ability for Tom, Dick, or Harry to be
> able to crank
On Sun, 04 Jan 2009 15:58:34 CST, Joe Greco said:
> > Technically the only thing necessary to prevent
> > this attack has already been done, and that is to stop issuing certs
> > signed with MD5 so that no one else can create a rogue CA via this
> > means.
>
> Are we certain that existing
> "SSL is cracked, VeriSign to blame!" was pretty much the top security
> story for several days. They had to do something to turn around the
> perception, despite accurate analysis and publications by
> organizations such as Microsoft. Perception is reality, and
> regardless of the techn
On Jan 4, 2009, at 12:05 PM, Joe Greco wrote:
The opinions on whether or not it is necessary to replace certs
seems to
vary depending on whose opinion you're listening to, but a
relatively safe
rule of thumb for this sort of security issue is to take the path
that is
most likely to avoid r
> Date: Sun, 04 Jan 2009 09:22:06 +0200
> From: Hank Nussbacher
>
> At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote:
> >On Sat, 3 Jan 2009, Hank Nussbacher wrote:
> >
> >>You mean like for BGP neighbors? Wanna suggest an alternative? :-)
> >
> >Well, most likely MD5 is better than the alter
> * Brian Keefer:
> > My apologies if you were commenting on some other aspect, or if my
> > understand is in some way flawed.
>
> I don't think so.
>
> There's a rule of thumb which is easy to remembe: Never revoke
> anything just because some weak algorithm is involved. The rationale
> is that
On Sun, Jan 4, 2009 at 11:40 AM, Christopher Morrow
wrote:
> On Sun, Jan 4, 2009 at 9:37 AM, Marshall Eubanks
> wrote:
>> There is a discussion of this going on in CFRG.
>>
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
> sadly, and apropos I suppose, www.irtf.org is serving up a *.ietf.org
On Sun, Jan 4, 2009 at 9:37 AM, Marshall Eubanks wrote:
> There is a discussion of this going on in CFRG.
>
> https://www.irtf.org/mailman/listinfo/cfrg
>
sadly, and apropos I suppose, www.irtf.org is serving up a *.ietf.org
ssl cert :( and the archives require membership to view them.
-chris
There is a discussion of this going on in CFRG.
https://www.irtf.org/mailman/listinfo/cfrg
Regards
Marshall
On Jan 4, 2009, at 2:22 AM, Hank Nussbacher wrote:
At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote:
On Sat, 3 Jan 2009, Hank Nussbacher wrote:
You mean like for BGP neighbors?
Yeap:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-02.txt
TCPM WGJ. Touch
Internet Draft USC/ISI
Obsoletes: 2385 A. Mankin
Inte
* Hank Nussbacher:
> Who is working on this? I don't find anything here:
> http://www.ietf.org/html.charters/idr-charter.html
I think this belongs to the tcpm WG or the btns WG.
At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote:
On Sat, 3 Jan 2009, Hank Nussbacher wrote:
You mean like for BGP neighbors? Wanna suggest an alternative? :-)
Well, most likely MD5 is better than the alterantive today which is to run
no authentication/encryption at all.
But we should
On Sat, 03 Jan 2009 17:23:06 +0100, Florian Weimer said:
> Our rationale is that in order to carry out currently known attacks on
> MD5, you need to create a twin of documents, one evil and one
> harmless. In Debian's case, we prepare the data we sign on our
> trusted infrastructure. If someone c
On Sat, Jan 3, 2009 at 1:41 PM, Nick Hilliard wrote:
> Christopher Morrow wrote:
>> This is a function of an upgrade (firefox3.5 coming 'soon!') for
>> browsers, and for OS's as well, yes? So, given a future flag-day (18
>> months from today no more MD5, only SHA-232323 will be used!!)
>> browsers
> What's the cost to switching to something other than MD5 here,
> though?
Just the general risk of change (sometimes referred to as "bricking").
The changes on the generating side have already been implemented.
Maybe we should include a dummy package entry at the beginning of the
package list, w
* Frank Bulk:
> For me the MD5 hashes on file downloads are more valuable to ensure the
> package is accurate to a byte rather than to verify its authenticity or
> integrity.
Indeed. I've experienced that first-hand: the hashes helped to
isolate a case of faulty router memory at the ISP I used a
* Nick Hilliard:
> I think you might be downplaying the size of the problem here. X.509 and
> TLS/SSL isn't just used for browsers, but for a wide variety of places
> where there is a requirement for PKI based security. So when you talk
> about a flag day for dealing with SHA-X (where X != 1), h
* Hank Nussbacher:
> On Fri, 2 Jan 2009, Mikael Abrahamsson wrote:
>
>> MD5 is broken, don't use it for anything important.
>
> You mean like for BGP neighbors?
Good point. However, as a defense against potential blind injection
attacks, even an unhashed password in a TCP option would do the tri
ian Weimer [mailto:f...@deneb.enyo.de]
Sent: Saturday, January 03, 2009 10:23 AM
To: Skywing
Cc: NANOG
Subject: Re: Security team successfully cracks SSL using 200 PS3's
and MD5
flaw.
Then again, I just got yet another Debian DSA mail which has
plaintext download links for new binaries. T
Hank Nussbacher wrote:
> You mean like for BGP neighbors? Wanna suggest an alternative? :-)
tcp/md5 + gtsm (assuming directly connected peers) makes messing around
with bgp sessions rather difficult. Filtering BGP packets at the edge and
borders slightly more so. If you have CPU and sufficient
Christopher Morrow wrote:
> This is a function of an upgrade (firefox3.5 coming 'soon!') for
> browsers, and for OS's as well, yes? So, given a future flag-day (18
> months from today no more MD5, only SHA-232323 will be used!!)
> browsers for the majority of the market could be upgraded. Certainly
On Sat, 3 Jan 2009 12:31:53 -0500
"Christopher Morrow" wrote:
> On Sat, Jan 3, 2009 at 10:49 AM, Steven M. Bellovin
> wrote:
> > On Sat, 03 Jan 2009 09:35:06 -0500
> > William Warren wrote:
> >
> >> Everyone seems to be stampeding to SHA-1..yet it was broken in
> >> 2005. So we trade MD5 for SH
er
Sent: Saturday, January 03, 2009 08:23
To: Skywing
Cc: Steven M. Bellovin ; NANOG
Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
> Then again, I just got yet another Debian DSA mail which has
> plaintext download links for new binaries. The in
urity team successfully cracks SSL using 200 PS3's and MD5
flaw.
> Then again, I just got yet another Debian DSA mail which has
> plaintext download links for new binaries. The integrity
> verification mechanism for said binaries is, you guessed it:
> PGP-signed md5sums.
I c
On Sat, 3 Jan 2009, Hank Nussbacher wrote:
You mean like for BGP neighbors? Wanna suggest an alternative? :-)
Well, most likely MD5 is better than the alterantive today which is to run
no authentication/encryption at all.
But we should push whoever is developing these standards to go for S
On Sat, Jan 3, 2009 at 10:49 AM, Steven M. Bellovin
wrote:
> On Sat, 03 Jan 2009 09:35:06 -0500
> William Warren wrote:
>
>> Everyone seems to be stampeding to SHA-1..yet it was broken in 2005.
>> So we trade MD5 for SHA-1? This makes no sense.
>>
> (a) SHA-1 was not broken as badly. The best
Hank Nussbacher wrote:
> On Fri, 2 Jan 2009, Mikael Abrahamsson wrote:
>
>> MD5 is broken, don't use it for anything important.
>
> You mean like for BGP neighbors? Wanna suggest an alternative? :-)
>
MD5 on BGP sessions has already been proven to not being that effective
anyhow, for the purpo
On Fri, 2 Jan 2009, Mikael Abrahamsson wrote:
MD5 is broken, don't use it for anything important.
You mean like for BGP neighbors? Wanna suggest an alternative? :-)
-Hank
> Then again, I just got yet another Debian DSA mail which has
> plaintext download links for new binaries. The integrity
> verification mechanism for said binaries is, you guessed it:
> PGP-signed md5sums.
I can assure you that you will continue to receive these messages for
a while (unless you
On Sat, 03 Jan 2009 09:35:06 -0500
William Warren wrote:
> Everyone seems to be stampeding to SHA-1..yet it was broken in 2005.
> So we trade MD5 for SHA-1? This makes no sense.
>
(a) SHA-1 was not broken as badly. The best attack is, as I recall,
2^63, which is computationally infeasible with
* Brian Keefer:
> My apologies if you were commenting on some other aspect, or if my
> understand is in some way flawed.
I don't think so.
There's a rule of thumb which is easy to remembe: Never revoke
anything just because some weak algorithm is involved. The rationale
is that that revocation
On Jan 3, 2009, at 9:38 AM, Dorn Hetzel wrote:
Would using the combination of both MD5 and SHA-1 raise the
computational
bar enough for now,
I have never seen this recommended (and I do try and follow this).
or are there other good prospects for a harder to crack
hash?
The Federal Infor
Would using the combination of both MD5 and SHA-1 raise the computational
bar enough for now, or are there other good prospects for a harder to crack
hash?
On Sat, Jan 3, 2009 at 9:35 AM, William Warren <
hescomins...@emmanuelcomputerconsulting.com> wrote:
> Dragos Ruiu wrote:
>
>>
>> On 2-Jan-09
Dragos Ruiu wrote:
On 2-Jan-09, at 9:56 AM, Robert Mathews (OSIA) wrote:
Joe Greco wrote:
[ ]
Either we take the potential for transparent MitM attacks seriously, or
we do not. I'm sure the NSA would prefer "not." :-)
As for the points raised in your message, yes, there are addition
* Joe Greco:
>> A CA statement that they won't issue MD5-signed certificates in the
>> future should be sufficient. There's no need to reissue old
>> certificates, unless the CA thinks other customers have attacked it.
>
> That would seem to be at odds with what the people who documented this
>
On Jan 2, 2009, at 3:29 PM, Joe Greco wrote:
* Joe Greco:
It seems that part of the proposed solution is to get people to
move from
MD5-signed to SHA1-signed. There will be a certain amount of
resistance.
What I was suggesting was the use of the revocation mechanism as
part of
the "stick
On Fri, Jan 2, 2009 at 10:44 PM, Dragos Ruiu wrote:
>
> On 2-Jan-09, at 6:53 PM, Gadi Evron wrote:
>>
>> Yes, this is a serious matter, but it hardly has any operational impact to
>> speak of for users and none for NSPs.
>
> Dunno. Last I checked NSPs had web servers too. :-P
so, aside from 'get
On 2-Jan-09, at 6:53 PM, Gadi Evron wrote:
Yes, this is a serious matter, but it hardly has any operational
impact to speak of for users and none for NSPs.
Dunno. Last I checked NSPs had web servers too. :-P
cheers,
--dr
--
World Security Pros. Cutting Edge Training, Tools, and Techniques
> Neil wrote:
>
> >>Do people here really so quickly forget things? There was a talk on
> >>Carnivore given in 2000 at NANOG 20, IIRC, and I believe that one of the
> >>instigating causes of that talk was problems that Earthlink had experienced
> >>when the FBI had deployed Carnivore there.
>
>
On Fri, 2 Jan 2009, Dragos Ruiu wrote:
www.win.tue.nl/hashclash/rogue-ca/; classtype: policy-violation;
sid:101;)
You can't really use any snort rule to detect SHA-1 certs created by a
fake authority created using the MD5 issue.
Yes, this is a serious matter, but it hardly has any operat
On 2-Jan-09, at 9:56 AM, Robert Mathews (OSIA) wrote:
Joe Greco wrote:
[ ]
Either we take the potential for transparent MitM attacks
seriously, or
we do not. I'm sure the NSA would prefer "not." :-)
As for the points raised in your message, yes, there are additional
problems with
Neil wrote:
Do people here really so quickly forget things? There was a talk on
Carnivore given in 2000 at NANOG 20, IIRC, and I believe that one of the
instigating causes of that talk was problems that Earthlink had experienced
when the FBI had deployed Carnivore there.
Naturally. The NSA
On Fri, Jan 2, 2009 at 3:29 PM, Joe Greco wrote:
>> * Joe Greco:
[snip
>> > Either we take the potential for transparent MitM attacks seriously, or
>> > we do not. I'm sure the NSA would prefer "not." :-)
>>
>> I doubt the NSA is interested in MITM attacks which can be spotted by
>> comparing ke
> * Joe Greco:
> > It seems that part of the proposed solution is to get people to move from
> > MD5-signed to SHA1-signed. There will be a certain amount of resistance.
> > What I was suggesting was the use of the revocation mechanism as part of
> > the "stick" (think carrot-and-stick) in a campa
> If you use bad crypto, you lose no matter what. If you use good
> crypto, 2,000,000,000 PS3s won't do the job.
>
Even if you use good crypto, and someone steals your key (say, a previously
in-access person) you need a way to reliably, completely, revoke it. This has
been a problem with SSL
it: PGP-signed md5sums.
We still have a long way to go. :)
– S
-Original Message-
From: Steven M. Bellovin
Sent: Friday, January 02, 2009 15:07
To: Skywing
Cc: Deepak Jain ; NANOG
Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
On Fri, 2 Jan 20
On Fri, 2 Jan 2009 16:51:53 -0600
Skywing wrote:
> Of course, md5 *used* to be good crypto.
>
See http://www.cs.columbia.edu/~smb/blog/2008-12/2008-12-30.html for
the links, but MD5 has been suspect for a very long time.
Dobbertin found problems with it in 1996. The need for caution with it
wa
Of course, md5 *used* to be good crypto.
– S
-Original Message-
From: Steven M. Bellovin
Sent: Friday, January 02, 2009 14:46
To: Deepak Jain
Cc: NANOG
Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5
flaw.
On Fri, 2 Jan 2009 16:13:45 -0500
D
On Fri, 2 Jan 2009 16:13:45 -0500
Deepak Jain wrote:
> > If done properly, that's actually an easier task: you build the
> > update key into the browser. When it pulls in an update, it
> > verifies that it was signed with the proper key.
> >
>
> If you build it into the browser, how do you rev
* Joe Greco:
> It seems that part of the proposed solution is to get people to move from
> MD5-signed to SHA1-signed. There will be a certain amount of resistance.
> What I was suggesting was the use of the revocation mechanism as part of
> the "stick" (think carrot-and-stick) in a campaign to re
a]
Sent: Friday, January 02, 2009 11:40 AM
To: Joe Greco
Cc: nanog@nanog.org
Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5
On 2 Jan 2009, at 12:33, Joe Greco wrote:
> We cannot continue to justify security failure on the basis that a
> significant
> On 2 Jan 2009, at 12:33, Joe Greco wrote:
>
> > We cannot continue to justify security failure on the basis that a
> > significant percentage of the clients don't support it, or are
> > broken in
> > their support. That's an argument for fixing the clients.
>
> At a more basic level, though,
anuary 02, 2009 4:14 PM
To: Steven M. Bellovin
Cc: NANOG
Subject: RE: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
> If done properly, that's actually an easier task: you build the update
> key into the browser. When it pulls in an update, it verifies that
> ssl itself wasn't cracked they simply exploited the known vulnerable
> md5
> hashing. Another hashing method needs to be used.
The encryption algorithm wasn't hacked. Correct. Another hashing method
may help. Yup.
My problem is with the chain-of-trust and a lack of reasonable or reasonably
> If done properly, that's actually an easier task: you build the update
> key into the browser. When it pulls in an update, it verifies that it
> was signed with the proper key.
>
If you build it into the browser, how do you revoke it when someone throws 2000
PS3s to crack it, or your hash, or
Rodrick Brown wrote:
A team of security researchers and academics has broken a core piece
of Internet technology. They made their work public at the 25th Chaos
Communication Congress in Berlin today. The team was able to create a
rogue certificate authority and use it to issue valid SSL certifica
On Fri, 2 Jan 2009 15:49:24 -0500
Deepak Jain wrote:
> > Of course, this will just make the browsers pop up dialog boxes
> > which everyone will click OK on...
> >
>
> And brings us to an even more interesting question, since everything
> is trusting their in-browser root CAs and such. How trus
> Of course, this will just make the browsers pop up dialog boxes which
> everyone will click OK on...
>
And brings us to an even more interesting question, since everything is
trusting their in-browser root CAs and such. How trustable is the auto-update
process? If one does provoke
a mass-revo
On 3/01/2009, at 6:06 AM, Steven M. Bellovin wrote:
On Fri, 2 Jan 2009 17:53:55 +0100
"Terje Bless" wrote:
On Fri, Jan 2, 2009 at 5:44 PM, wrote:
Hmm... so basically all deployed FireFox and IE either don't even
try to do a CRL, or they ask the dodgy certificate "Who can I ask
if you're do
Joe Greco wrote:
> [ ]
>
> Either we take the potential for transparent MitM attacks seriously, or
> we do not. I'm sure the NSA would prefer "not." :-)
>
> As for the points raised in your message, yes, there are additional
> problems with clients that have not taken this seriously. It
On 2 Jan 2009, at 12:33, Joe Greco wrote:
We cannot continue to justify security failure on the basis that a
significant percentage of the clients don't support it, or are
broken in
their support. That's an argument for fixing the clients.
At a more basic level, though, isn't failure guar
> On Fri, 02 Jan 2009 09:58:05 CST, Joe Greco said:
> > Anyways, I was under the impression that the whole purpose of the
> > revocation capabilities of SSL was to deal with problems like this, and
> > that a large part of the justification of the cost of an SSL certificate
> > was the administrati
On Fri, 2 Jan 2009 17:53:55 +0100
"Terje Bless" wrote:
> On Fri, Jan 2, 2009 at 5:44 PM, wrote:
> > Hmm... so basically all deployed FireFox and IE either don't even
> > try to do a CRL, or they ask the dodgy certificate "Who can I ask
> > if you're dodgy?"
>
> Hmm. Don't the shipped-with-the-
On Fri, Jan 2, 2009 at 5:44 PM, wrote:
> Hmm... so basically all deployed FireFox and IE either don't even try to do
> a CRL, or they ask the dodgy certificate "Who can I ask if you're dodgy?"
Hmm. Don't the shipped-with-the-browser trusted root certificates
include a CRL URL?
On Fri, 02 Jan 2009 09:58:05 CST, Joe Greco said:
> Anyways, I was under the impression that the whole purpose of the
> revocation capabilities of SSL was to deal with problems like this, and
> that a large part of the justification of the cost of an SSL certificate
> was the administrative burden
On Fri, 2 Jan 2009, Joe Greco wrote:
Anyways, I was under the impression that the whole purpose of the
revocation capabilities of SSL was to deal with problems like this, and
How to revoke the CA is actually in the file. The fake CA they created
didn't have any revokation.
MD5 is broken, do
On Fri, 2 Jan 2009, Joe Abley wrote:
On 2009-01-02, at 09:04, Rodrick Brown wrote:
A team of security researchers and academics has broken a core piece
of Internet technology. They made their work public at the 25th Chaos
Communication Congress in Berlin today. The team was able to create a
ro
Joe Abley wrote:
>
> On 2009-01-02, at 09:04, Rodrick Brown wrote:
>
>> A team of security researchers and academics has broken a core piece
>> of Internet technology. They made their work public at the 25th Chaos
>> Communication Congress in Berlin today. The team was able to create a
>> rogue c
On 2009-01-02, at 09:04, Rodrick Brown wrote:
A team of security researchers and academics has broken a core piece
of Internet technology. They made their work public at the 25th Chaos
Communication Congress in Berlin today. The team was able to create a
rogue certificate authority and use it t
> A team of security researchers and academics has broken a core piece
> of Internet technology. They made their work public at the 25th Chaos
> Communication Congress in Berlin today. The team was able to create a
> rogue certificate authority and use it to issue valid SSL certificates
> for any s
82 matches
Mail list logo
