Re: Comcast security please contact me off list
On Sat, Oct 22, 2011 at 12:56 AM, N Rauhauser neal.rauhau...@gmail.com wrote: I do some protective service work, one client is the head of a Washington D.C. NGO that faced a credible death threat last month. Tonight I received information that the source of this threat traced one of the NGO's volunteers to her home address via Comcast IP, and the location is a relatively short drive away from a man who was arrested last month for criminal harassment almost five hundred miles from his home. I have some genuine concerns for the physical safety of this Comcast customer, and I'd like to talk to someone immediately. We've got an annoyed FBI agent who will confirm the back story on this Monday, but the subjects know they're under some sort of investigation and I'm afraid of what might happen if further info leaks over the weekend. Then your FBI agent should probably go through the channels (http://security.comcast.net/get-help/contact-comcast-security.aspx) they have to speak to Comcast, especially if it involves a threat to life and safety. Asking on NANOG for a Comcast contact to give you customer information (which is what it seems like you're asking for) probably isn't going to help and makes it look more like you're trying to social engineer some information than trying to help someone. Bob
Re: Juniper DOS/Blackhole question
On (2011-10-22 20:38 -0500), Jack Bates wrote: the route. This seems strange to me. Any idea why a route would be rejected unless multihop was enabled? RFC4271 states: -- - By default (if none of the above conditions apply), the BGP speaker SHOULD use the IP address of the interface that the speaker uses to establish the BGP connection to peer X in the NEXT_HOP attribute. -- Your provider was rewriting the next-hop to some address they are blackholing inside their network. This caused above check to fail, and route was being considered invalid. EBGP multihop is kludge to kill this check, but also kludge to kill convergence of your BGP session, due to disabling fall over on linkdown. Proper way to disable this check is JunOS 'accept-remote-nexthop' or IOS 'disable-connected-check'. -- ++ytti
Re: Juniper DOS/Blackhole question
On 10/23/2011 2:18 AM, Saku Ytti wrote: EBGP multihop is kludge to kill this check, but also kludge to kill convergence of your BGP session, due to disabling This is what I was worried about. fall over on linkdown. Proper way to disable this check is JunOS 'accept-remote-nexthop' or IOS 'disable-connected-check'. Thanks. I'll have them fix it proper then. Jack
Re: Facebook insecure by design
Just about everything on Google pages is https these days, even search if you enable it. If anybody on this thread uses gmail com a you really ought to take a look at google plus. Compare the way user privacy is the primary objective, versus the share everything by default of facebook. I cannot think of anything that could do something like this in the Gmail or Plus products. On Oct 19, 2011 11:22 PM, Murtaza leothelion.murt...@gmail.com wrote: Going back to the initial security problem identified by Williams, I also experienced something today. I guess he is right about that. I am behind a proxy and I just disabled the proxy for Secure Web which means HTTPS. Now guess what I was still able to access facebook while I was not able to access google. That clearly means there is something wrong. What do you guys think? Ghulam On Wed, Oct 5, 2011 at 2:28 AM, Bill.Pilloud bill.pill...@gmail.com wrote: Is this not the nature of social media? If you want to make sure something is secure (sensitive information), Why is it on social media. If you are worried about it being monetised, I think Google has already done that. - Original Message - From: Joel jaeggli joe...@bogus.com To: Jimmy Hess mysi...@gmail.com Cc: nanog@nanog.org Sent: Sunday, October 02, 2011 4:05 PM Subject: Re: Facebook insecure by design On 10/2/11 15:43 , Joel jaeggli wrote: On 10/2/11 15:25 , Jimmy Hess wrote: On Sun, Oct 2, 2011 at 4:53 PM, valdis.kletni...@vt.edu wrote: On Sun, 02 Oct 2011 08:38:36 PDT, Michael Thomas said: I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise. Ooh.. subtle. :) Man in the Middle (MITM) is a technical term that refers to a rather specific kind of attack. In this case, I believe the proper term would be just The man. [Or Man at the Other End (MATOE)]; you either trust Facebook with info to send to them or you don't, and network security is only for securing the transportation of that information you opt to send facebook. alice sends charlie a message using bob's api, bob can observe and probably monetize the contents. Yes, if Alice sends Bob an encrypted message that Bob can read, and Bob turns out to be untrustworthy, then Bob can sell/re-use the information in an abusive/unapproved way for personal or economic profit. charlie is probably untrustworthy, bob is probably moreso (mostly ^ trustworthy because bob has more to lose than charlie), alice isn't cognizant of the implications of running charlie's app on bob's platform despite the numerous disclaimers she blindly clicked through on the way there. -- -JH
Re: Facebook insecure by design
[hmmm this subject is not really ops now is it...] On 2011-10-23 19:43 , steve pirk [egrep] wrote: Just about everything on Google pages is https these days, even search if you enable it. (or just use https://encrypted.google.com which is available for quite some time already) If anybody on this thread uses gmail com a you really ought to take a look at google plus. Compare the way user privacy is the primary objective, versus the share everything by default of facebook. Since when is encrypting a transport (in this case using TLS/SSL) 'user privacy' ? The only thing it is protecting is intermediate networks sniffing or even modifying the traffic and more importantly for the company who gets all your private information: their revenue stream when they sell that data. And really, giving all your private emails to a company that explicitly reads them (even if it is 'automated') to advertise to you and then mentioning 'user privacy' is just ridiculous ;) Greets, Jeroen
Re: Facebook insecure by design
- Original Message - From: Jeroen Massar jer...@unfix.org On 2011-10-23 19:43 , steve pirk [egrep] wrote: Just about everything on Google pages is https these days, even search if you enable it. (or just use https://encrypted.google.com which is available for quite some time already) Note that Lauren Weinstein has just put out a Privacy Digest posting noting that the referer behavior differs between https://encrypted.google.com and https://www.google.com in a way that implies that, again, someone at Google may not have gotten the Don't Be Evil memo... http://lauren.vortex.com/archive/000906.html Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Facebook insecure by design
I follow Lauren on plus, and also on buzz, and we have discussed privacy stuff a lot. The way I look at it, unless you want to host everything yourself, you have to choose someone to be your Unix like home directory in the cloud. Of all the internet entities out there, Google has had the best track record of protecting your data. You can even download it all and erase yourself if you want out. Apps accounts and pseudonym accounts are coming soon. It was announced by Vic himself at web 2.0. I need to send that post by Lauren to the gmail account. He always finds good issues. It could be that I am off base. On Oct 23, 2011 4:04 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Jeroen Massar jer...@unfix.org On 2011-10-23 19:43 , steve pirk [egrep] wrote: Just about everything on Google pages is https these days, even search if you enable it. (or just use https://encrypted.google.com which is available for quite some time already) Note that Lauren Weinstein has just put out a Privacy Digest posting noting that the referer behavior differs between https://encrypted.google.com and https://www.google.com in a way that implies that, again, someone at Google may not have gotten the Don't Be Evil memo... http://lauren.vortex.com/archive/000906.html Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Facebook insecure by design
That was a most excellent example Jay. I see what the issue is now. This could be related to work Google did to plus shortly after launch. Buzz and now Google+ are https only. Google cooked up a URL processer that took clicks to external content like article links, and massaged the referrer be readable as http to show where the visitor came from. Sanitized of any personal data I assume. The problem they were trying to fix was no one knew any users were coming from Buzz clicks. They fixed that in +. I am thinking something of the same might fix the search issues. It could also be that a Googler saw Lauren's post and the debate has already started. -steve On Oct 23, 2011 4:04 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Jeroen Massar jer...@unfix.org On 2011-10-23 19:43 , steve pirk [egrep] wrote: Just about everything on Google pages is https these days, even search if you enable it. (or just use https://encrypted.google.com which is available for quite some time already) Note that Lauren Weinstein has just put out a Privacy Digest posting noting that the referer behavior differs between https://encrypted.google.com and https://www.google.com in a way that implies that, again, someone at Google may not have gotten the Don't Be Evil memo... http://lauren.vortex.com/archive/000906.html Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
