Re: Lawsuits for falsyfying DNS responses ?
On Mon, Sep 12, 2016 at 01:41:16PM -0400, Jean-Francois Mezei wrote: > Are there examples of an ISP getting sued because it redirected traffic > that should have gone to original site ? This happened with Paxfire (and the ISPs that used them) in 2011. https://www.eff.org/deeplinks/2011/07/widespread-search-hijacking-in-the-us http://www.courthousenews.com/2011/08/08/38796.htm Marcus
Re: NTP Server
On Sun, Oct 24, 2010 at 09:49:31AM -0700, Seth Mattinen wrote: > On 10/24/2010 09:26, Brandon Kim wrote: > > > > Wow that is amazing and quite impressive that you even run the antenna > > linesinteresting..do you have to pay for the GPS service? > > > > > Make your own simple GPS NTP clock source: > > http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm Or if the serial port introduces too much jitter for you: http://www.febo.com/time-freq/ntp/soekris/index.html Marcus
Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates
On Wed, Sep 07, 2011 at 09:17:10AM -0700, Network IP Dog wrote: > FYI!!! > > http://seattletimes.nwsource.com/html/microsoftpri0/2016132391_microsoft_dee > ms_all_diginotar_certificates_untrust.html > > Google and Mozilla have also updated their browsers to block all DigiNotar > certificates, while Apple has been silent on the issue, a emblematic zombie > response! Apple has sent out a notification saying that they are removing DigiNotar from their list of trusted root certs. I like this response; instant CA death penalty seems to put the incentives about where they need to be. Marcus
Re: Microsoft deems all DigiNotar certificates untrustworthy, releases
On Sun, Sep 11, 2011 at 01:34:43PM -0500, Joe Greco wrote: > > > Because of that lost trust, any cross-signed cert would likely be revoked > > > by > > > the browsers. It would also make the browser vendors question whether the > > > signing CA is worthy of their trust. > > > > To pop up the stack a bit it's the fact that an organization willing to > > behave in that fashion was in my list of CA certs in the first place. > > Yes they're blackballed now, better late than never I suppose. What does > > that say about the potential for other CAs to behave in such a fashion? > > The average corporation much prefers to avoid the bad publicity and will > downplay most bad things. Your favorite CA probably included. > > I think that it's hard to cope with SSL. It doesn't do the right things > for the right reasons. Many of us, for example, operate local root CA's > for signing of "internal" stuff; all our company gear trusts our local > root CA and lots of stuff has certs issued by it. In an ideal world, > this would mean that our gear talking to our gear is always secure, but > with other root CA's able to offer certs for our CN's, that isn't really > true. That's frustrating. You don't have to have the big fat Mozilla root cert bundle on your machines. Some OSes "ship" with an empty /etc/ssl, nobody tells you who you trust. > The reality is that - for the average user - SSL doesn't work well > unless about 99% of the CA's used by the general public are included > as "trusted." If a popular site like Blooble has a cert by DigiNotar > and the Firerox browser is constantly asking what to do, nothing really > good comes out of that ... either people think Firerox blows, or they > learn to click on the "ignore this" (or worse the "always trust this") > button. In about 0.0% of the cases do they actually understand the > underlying trust issues. So there's a great amount of pressure to > just make it magically work. How about a TXT record with the CN string of the CA cert subject in it? If it exists and there's a conflict, don't trust it. Seems simple enough to implement without too much collateral damage. > However, as the number of CA's accepted in most browsers increases, > the security of the system as a whole decreases dramatically. Yet > the market for $1000/year SSL certs is rather low, and the guys that > are charging bargain rates for low quality certs are perhaps doing > one good thing (enabling encryption) while simultaneously doing another > bad thing (destroying any "quality" in the system). SSL is going to > have these problems as long as we maintain the current model. I like the added "chrome" that the new browsers have for EV certs, but users need to be stabbed in the face, green vs. blue doesn't really do it. > In the long run, I expect all the CA's to behave something like this - > especially the ones that have more to lose if they were to become > suddenly "untrustworthy." Yes, how do you think Verisign/Thawte/Symantec would behave if they found that their keys were compromised? They might do the right thing, because they're not stupid enough to think they could get away with trying to cover it up. What would the browser vendors do in that case? I hope there's a contingency plan, and if there is it seems like it should be made public. Marcus
Re: Why are we still using the CA model? (Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates)
On Mon, Sep 12, 2011 at 11:00:47PM +0100, Tony Finch wrote: > Note that a big weak point in the DNS is the interface between the > registrars and the registry. If you have a domain you have to trust the > registry to impose suitable restrictions on its registrars to prevent a > dodgy registrar from stealing your domain. Another, of course, is the > interface between a registrar and its customers. Just in case anybody missed it, ups.com, theregister.co.uk, and others were hijacked in this way last week. http://www.theregister.co.uk/2011/09/05/dns_hijack_service_updated/ Marcus
Re: Anyone from Covad here?
On Thu, Sep 15, 2011 at 07:20:04PM -0700, Robert Glover wrote: > Covad (or should I say Megapath now..), > > You have DNS servers that are failing to resolve anything at this time: > > 64.105.172.26 and 64.105.172.27 are both failing. > > This is a Bad Thing as these are the servers that the majority of our > Covad customers use. Called it in to the right guy. Marcus
Re: Netflix And AT&T Sign Peering Agreement
On Wed, Jul 30, 2014 at 11:21:05PM -0400, Jay Ashworth wrote: > - Original Message - > > From: "Jay Ashworth" > > > > Previously, Netflix signed similar agreements with Comcast and > > > Verizon. > > > > > > http://techcrunch.com/2014/07/29/netflix-and-att-sign-peering-agreement/ > > > > Am I nuts in thinking that *someone* has mispelt "Netflix agrees to > > buy transit from AT&T"? > > As several people were kind enough to point out to me off-list, "yes" > is the answer to that question. Thanks Jay. Can you put it in a nutshell just in case others are a little vague on the finer points of these arrangements and their significance in the current content provider / network provider row? The best thing about journalists is that they're always right (unless they're writing about something you know about, in which case they seem to always screw it up.) I like how in this case the author declares that "This is the new normal." Marcus
Re: Dynamic IP log retention = 0?
On Wed, Mar 11, 2009 at 10:55:43AM -0400, Brett Charbeneau wrote: > On Wed, 11 Mar 2009, William Allen Simpson wrote: > > WAS> While I applaud your taking security seriously, and your active > monitoring > WAS> of your resources, other folks might be handling huge numbers of > Conficker, > WAS> Mebroot, and Torpig infections these days. So, they might be rather > busy. > > Excellent point. And with dwindling staff levels outgoing worm traffic > may be super low priority for them. > I know every operation is different - I just wanted to check with the > group before cranking up my level of indignation. =8^) > > WAS> Are your library systems all clean? > > I believe them to be. I have a Snort-based network intrusion detection > system (using sguil) running with eight taps - and we subscribe to the Snort > VRT > rules. That's on top of host-based intrusion (OSSEC) on all of our servers > and > critical workstations. And centrallly-manged anti-virus (Kaspersky) on all > desktops. > > WAS> You don't seem to have your own ARIN allocation for wrl.org, so it's > kinda > WAS> hard to tell from here > WAS> > WAS> AS | IP | AS Name > WAS> 4565| 66.200.204.71| MEGAPATH2-US - MegaPath Networks Inc. > > Yes - while we handle our own DNS our ISP prefers to mask our ARIN > entry for (their) ease of management. I try to be the anti-salmon with this > and > go WITH the flow... A quick scan of the reverse mapping for your address space in DNS reveals that you have basically your entire network on public addresses. No wonder you're worried about portscans when the printer down the hall and the receptionists machine are sitting on public addresses. I think you are trying to secure your network from the wrong end here. Marcus
Re: Anyone see a game changer here?
On Fri, Jan 15, 2010 at 10:20:33AM -0500, Marshall Eubanks wrote: >Where are these quotes coming from ? That particular one: http://redtape.msnbc.com/2010/01/gregory-fayer-opened-an-e-mail-on-monday-night-that-looked-like-it-was-from-a-fellow-lawyer-at-gipson-hoffman-pancione-inst.html Some more commentary: http://www.wired.com/threatlevel/2010/01/operation-aurora/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+wired27b+%28Blog+-+27B+Stroke+6+%28Threat+Level%29%29&utm_content=Google+Reader Of course, you'll have to follow links in an email in order to read those, if you dare. Marcus
Re: lawful intercept/IOS at BlackHat DC, bypassing and recommendations
On Thu, Feb 04, 2010 at 09:42:24PM -0500, Steven Bellovin wrote: >I can make a very good case that CALEA was not just originally intended > for voice, but was sold to Congress as something that didn't apply to data > networks. The EFF has said it better than I could, though, so look at > http://w2.eff.org/Privacy/Surveillance/20040413_EFF_CALEA_comments. Corrected URL: http://w2.eff.org/Privacy/Surveillance/20040413_EFF_CALEA_comments.php
