Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] root CA bloat



On Sun, Nov 23, 2014 at 3:53 PM, Richard Pieri <richard.pieri at gmail.com> wrote:
> On 11/23/2014 3:26 AM, Bill Bogstad wrote:
>>
>> If they did something that Microsoft hadn't requested then I'm pretty
>> sure somebody would both notice AND care.  This is all in the context
>> of attacking the security of Internet communications via a MITM
>> attack.   If Microsoft (one of the two parties communicating
>> in this example) authorized it, then it isn't MITM.   Whether it
>
>
> Ahh. I see what you mean, now. Your argument, that because Microsoft /did/
> authorize MarkMonitor to act as an intermediary makes any interception not
> MITM since it's not an unauthorized party listening in, has merit.

Almost...   Microsoft didn't authorize MarkMonitor to monitor their
communications (as far as I know).   They authorized them to provide
DNS related services.   So if MarkMonitor did this, then I would call
it a MITM attack.   My point is more that if they did do it, I believe
that it would be very public that something funny was happening.   The
"cost" to MarkMonitor for doing this would be so high that I don't see
them doing it voluntarily.   Now if this was really end of the world
type stuff, someone might convince/force them to do it anyway.   In
that case though, I think the parities involved would just go to
Microsoft and get copies from them.   Much less likely for anyone to
ever know.  An alternative scenario where someone breaks into MM and
does this is worth considering.
By using MM, Microsoft is increasing the attack scope on their
communications.   Of course, Microsoft is also dependent on the
security of all CAs, top level DNS servers, etc.   The problems with
CA delegation seem much more significant then this one though.   Until
we get a solution to that problem, I'm not going to worry about this
one.

Bill Bogstad



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org