g-clef

Having worked defensive infosec for almost 2 decades, the privacy-invasion-leading-to-insecure-workarounds is not my experience. (US-based, I'll grant. I'm sure my experience would be different in Germany, for example.)

As long as the inspection was transparent (which it was until the TLS 1.3 discussion started), employees mostly didn't know they were being monitored, and they didn't care even when they learned they were. Folks who got caught downloading porn or running their side-business over the work network were surprised that we were looking for that stuff, but no one felt like their privacy had been violated.

Defensive infosec is mostly "liability and risk reduction." Why is "risk reduction" seen as a bad thing?

> I have a hard time to comprehend how this can be considered a reasonable security measure.

OK, let's walk it through.

Task: block access to "attacker.com" and all it's subdomains. Reason: Maybe it's a malware command and control, maybe it's being used for DNS tunneling, whatever. Blocking a domain that's being used for malicious behavior is a reasonable thing for an enterprise to want to accomplish.

Option 1: Block by IP at the firewall. Problems: Attackers can simply point the domain to another IP, so you're constantly playing whack-a-mole and constantly behind the attacker. Also, if it's a DNS tunnel the DNS answer is what's interesting, not the traffic to the actual IP. Result: Fail, doesn't solve the problem.

Option 2: Block by DNS Name at the firewall. Problems: Requires the firewall to understand the protocols involved, which they have shown themselves to be inconsistent at, at the best of times. Also, doing regex on every DNS query packet(in order to find all subdomains) doesn't scale. Result: Fail, doesn't scale.

Option 3: Block with local agent. Problems: Tablets, phones, appliances, printers can't run a local agent. Result: Fail. Not complete coverage

Option 4: Block outbound DNS except for approved resolvers, give those resolvers an RPZ feed of malicious domains. Problem: Clients have to be configured to use those resolvers, but otherwise none. Result: Pass. It's standards compliant, and DNSSec isn't an issue since the resolver never asks for the attackers DNS answer, so they never get the chance to offer DNSSec.

That's why option 4 (or some variant of it) is popular in enterprises. It accomplishes the task in a standards-compliant way, and covers the entire enterprise in a way that scales well.

DOH blows this up. So, the question becomes: in a world with DOH, how is an enterprise supposed to completely and scalably block access to "attacker.com" and all its subdomains? So far, the answer has been "you don't." I think that is a really shitty answer to someone who's trying to accomplish something reasonable.

I'm really struck by how hostile to enterprise security these proposals are. Yes, I know that the security folks will adapt (they'll have to), but it still feels like there's a lot of baby+bathwater throwing going on.

DNS over HTTP is a prime example: blocking outbound DNS for all but a few resolvers, and monitoring the hell out of the traffic on those resolvers is a big win for enterprise networks. What the RFC calls hostile "spoofing" of DNS responses enterprise defenders call "sinkholing" of malicious domains. Rather than trying to add a layer of validation to DNS to provide the end user with assurance that the DNS request they got really is the name they asked for (and, in theory, allow the enterprise to add their own key to sign sinkhole answers) instead DOH just throws the whole thing out...basically telling enterprise defenders "fuck your security controls, we hate Comcast too much to allow anyone to rewrite DNS answers."

"Fuck your security controls, we hate Comcast" is, I think, a bad philosophy for internet-wide protocols. (That's basically what the TLS 1.3 argument boils down to also...and that's a shame.)

You don't. You record it and replay it. You want the client to get the same packet 3 over and over.

Not quite: The attacker watches for the initial client->AP encryption negotiation (or forces it by forcing a disassociate), records one step of that negotiation and replays it to the client. That has the side-effect of causing the client->AP traffic to re-use encryption keys. Since WPA2 encryption is a stream cipher, re-using keys opens it up to a known-traffic analysis attack, which allows a listener to decrypt the traffic. So, the user is still connected to their existing AP, but since they're re-using keys, attackers can decrypt the client->AP communication.

There's no need for a second AP in all this, just someone in range of the client who can replay packets to the clients.

(Good TLDR here: https://blog.cryptographyengineering.com/2017/10/16/falling-... )

Those aren't drug dealers (I've met a few, they didn't act like that...either that or I only met the really boring drug dealers). The only place you see "drug dealers" acting like that is tv/movies.

"Suspicious" is walking up to the front door of your house and checking if it's locked. It's walking into your backyard without permission. It's looking in the windows of your house without permission. It's checking the doors on your car to see if they're unlocked. I'll even grant you that suspicious could be hanging out in a running car in front of an empty house for 30 minutes or so. However, it's not dressing flashy and being loud. (Though feel free to call the cops if they're being super-loud at 1am in a residential area. That's just rude.)

If your definition of "suspicious" includes "this person doesn't act like me" with a dollop of "this person acts like the cartoon black people I see in movies", then you should absolutely be prepared to be called out.

King & Union | Front-end developer | Washington, DC | ONSITE FULL-TIME

The point: We are making the threat intelligence process run more smoothly and helping organizations share threat data better. Our solution pulls threat information (both our own and via external APIs) into a graph and enables real-time collaboration and sharing of the information on the graph.

What we're looking for: We're looking for a mid/advanced front-end developer to take over development of our sites UI (we're in-housing development of the site after contracting it out for about a year). The front-end is built with React/Microcosm/Material/Vis.js, and it talks to our backend using a mix of REST and WebSockets. Ideally, the person we're looking for would be comfortable doing both the React programming side of things as well as the HTML/CSS/layout work. There would also be some design work as we roll out new features to the site.

Perks of the job: early round shares, competitive salary, 401k, & healthcare benefits. Also, we work from home a lot and our focus is on getting the work done, not on attendance or face time.

A bit about us: We are a pre-A-round startup. We have a working product and paying customers, so we're in a good spot financially. We are based in Alexandria, VA but do a lot of working from home, and tend to meet up in Alexandria once a week or so. Also, since we have an existing contracting relationship for our UI development, we're very flexible about start dates for this position.

If you are at all interested, please send me a message: aaron@kingandunion.com

Thought 1: Correlation/causation. It's not clear if the house causes the higher likelihood of failure or if the folks who are more likely to fail are drawn to the house. I can see arguments for both.

Thought 2: I don't think Wired is trying to write a story about intrigue as much as using the Senior House story to illustrate the larger trend of universities becoming more homogenous.

Writing a story that says "Universities are getting boring. 3 universities closed their counter-culture houses in the past year. Here's some quotes from people" is going to be, frankly, boring to read. On the other hand, a story that says "3 universities closed their counter-culture houses in the past year. Here's the story of one of them" is going to be much more compelling. It makes the story more personal, and therefore easier to understand and relate to.

From the article:

The demise of Senior House is emblematic of a larger shift on campuses across the US. Last year my own alma mater, Wesleyan University, closed down its countercultural house Eclectic, which had existed for a century. A few years ago Cal-Tech shuttered its countercultural dorm Ricketts. “If it were just Senior House I would be upset and sad,” says alumna Christine Corbett Moran, an astrophysicist and engineer who, after graduation, helped write the code for the encrypted chat app Signal. “But I really see it as a harbinger of MIT and other colleges homogenizing and corporatizing.”

King & Union | Front-end developer | Washington, DC | ONSITE FULL-TIME

The point: We are making the threat intelligence process run more smoothly and helping organizations share threat data better. Our solution pulls threat information (both our own and via external APIs) into a graph and enables real-time collaboration and sharing of the information on the graph.

What we're looking for: We're looking for a mid/advanced front-end developer to take over development of our sites UI (we're in-housing development of the site after contracting it out for about a year). The front-end is built with React/Microcosm/Material/Vis.js, and it talks to our backend using a mix of REST and WebSockets. Ideally, the person we're looking for would be comfortable doing both the React programming side of things as well as the HTML/CSS/layout work. There would also be some design work as we roll out new features to the site.

Perks of the job: early round shares, competitive salary, 401k, & healthcare benefits. Also, we work from home a lot and our focus is on getting the work done, not on attendance or face time.

A bit about us: We are a pre-A-round startup. We have a working product and paying customers, so we're in a good spot financially. We are based in Alexandria, VA but do a lot of working from home, and tend to meet up in Alexandria once a week or so. Also, since we have an existing contracting relationship for our UI development, we're very flexible about start dates for this position.

If you are at all interested, please send me a message: aaron@kingandunion.com

Everything you do is political in some way. Saying that you're worried about DNS becoming a political football implies it isn't already. It is. From ICANN's self-serving lunacy (don't lift that rock unless you have time to go down some very deep and fairly scuzzy rabbit holes), to domain seizures by governments (and private companies like Microsoft), DNS is already political. So is every other part of the internet infrastructure. Examples: the great firewall of china, registering to get porn in the UK [1], payment processors refusing to handle donations to Wikileaks [2].

The question isn't "should DNS and/or Internet infrastructure be political?"...because it already is. The question is "whose politics should it follow?"

[1]: http://www.businessinsider.com/uk-government-force-porn-site...

[2]: https://www.wired.com/2010/12/paypal-wikileaks/

King & Union | Front-end developer | Washington, DC | ONSITE FULL-TIME

The point: We are making the threat intelligence process run more smoothly and helping organizations share threat data better. Our solution pulls threat information (both our own and via external APIs) into a graph and enables real-time collaboration and sharing of the information on the graph.

What we're looking for: We're looking for a mid/advanced front-end developer to take over development of our sites UI (we're in-housing development of the site after contracting it out for about a year). The front-end is built with React/Microcosm/Material/Vis.js, and it talks to our backend using a mix of REST and WebSockets. Ideally, the person we're looking for would be comfortable doing both the React programming side of things as well as the HTML/CSS/layout work. There would also be some design work as we roll out new features to the site.

Perks of the job: early round shares, competitive salary, 401k, & healthcare benefits. Also, we work from home a lot and our focus is on getting the work done, not on attendance or face time.

A bit about us: We are a pre-A-round startup. We have a working product and paying customers, so we're in a good spot financially. We are based in Alexandria, VA but do a lot of working from home, and tend to meet up in Alexandria once a week or so. Also, since we have an existing contracting relationship for our UI development, we're very flexible about start dates for this position.

If you are at all interested, please send me a message: aaron@kingandunion.com

King & Union | Front-end developer | Washington, DC | ONSITE FULL-TIME

K&U is a pre-A-round security startup. We are trying to make the threat intelligence process run more smoothly and help organizations share threat data better. We're looking for a front-end developer to take over development of our applications UI (we're in-housing development of the app after contracting it out for about a year). The front-end is built with React/Microcosm/Material/Vis.js, and it talks to our backend using a mix of REST and WebSockets. Ideally, the person we're looking for would be comfortable doing both the React programming side of things as well as the HTML/CSS/layout work.

The job is based in the DC/Alexandria area, but we do a lot of working from home. Also, since we have an existing contracting relationship for development, we're very flexible about start dates. If you are at all interested, we encourage you to send us a note.

Please email a resume and some examples (or urls) of your work to aaron@kingandunion.com

The experts (no scare quotes needed, they really are experts) were commenting on the story's facts as presented. There was no need to read the source of whatsapp, as the facts as stated in the original article were overblown and based on fundamental misunderstandings of cryptography.

The entire story was based on the question of "what do you do when someone you're communicating with using encryption changes keys?" Whatsapp chose to dynamically use the new key, rather than fail & force the user to verify the new key in some out-of-band way. This was described as a "backdoor" in the guardian story. That was simply false. Even calling it a vulnerability is a mis-understanding of how cryptography works and of the risk involved in that design decision.

I feel like the rule should be fairly simple: your organization should match the ethnic and gender breakdown of the area it's offices are in.

So, for example, if Silicon Valley is 10% African Americans (I have no idea if that # if true, just using it for argument's sake), then your organization should be 10% African American. This also means your organization should be 50% women, since they are ~50% of the population. How you manage that (blind hiring, quota hiring, etc) is up to the company, and is difficult. But measuring proper diversity is really easy: you should reflect the local city's diversity. If you don't, you need to have a really good reason (and "we don't think we can be drinking buddies with them" is a really shitty reason).

Not only is hacking them illegal, but trying to sell them services after that could easily be seen as an attempt at blackmail. It's a profoundly bad idea.

That was my first thought when I saw the headline "I bet it's lxml". I have lost count of the number of times I've had to do special nonsense to handle lxml's memory leaks. (I've even had to go so far as to launch parsing code in a subprocess just so the part that created an etree object would quit & return all its RAM.)

Yeah, I noticed this at the time when I was looking for users resolving recently-registered domains (to try to find hacked systems). One of my users resolved & then went to ahhhhhhhhh.com, which had only been registered a few weeks beforehand.

Had my attention for a few minutes, but was ultimately not interesting (at least not from a security point of view).

I hear someone just released the full corpus of Reddit comments...

FYI, opennic is far more than just an alternative resolver to OpenDNS. OpenNIC is running an alternative set of roots, with TLDs that aren't agreed to by the regular DNS-managing bodies (like ICANN). That may be fine with you (opinion on ICANN's handling of new TLD's is a subject for another time), but be aware that you're seeing a different DNS with opennic than you would be with OpenDNS or google's 8.8.8.8

you'd handle that in the same way you'd handle it in IPv4: either a static assignment & a tracking process to avoid collisions, or static assignments in DHCP. DHCP6 does exist, and static assignments within a DHCP scope is a very common feature.

one caveat: DHCP6 is younger than IPv6, so not all router firmwares will have gotten around to implementing it yet.

Not necessarily. One of the interesting results from LADEE was that the measured lunar dust increased a few hours before the probe landed (attributed possibly to the geminid meteor shower). There's lots of stuff that can kick dust off the lunar surface.

http://en.wikipedia.org/wiki/Lunar_Atmosphere_and_Dust_Envir...

The moon is a pretty bad place for any long-term base...lunar dust is really hard on equipment. The l4/l5 points, though, are very interesting and there's a bunch of projects putting probes at the various l4/l5 points in the solar system.

http://en.wikipedia.org/wiki/List_of_objects_at_Lagrangian_p...

True. What most people are complaining about is that it's dynamically typed, not weakly typed. That's where most of the confusion sets in.

All of the people the EFF says to tweet to are Democrats...in a Republican-controlled house. This seems like an ineffectual strategy.

They should be trying to sway influential Republicans in the House, to make it clear that opposition to the TPP is bi-partisan. I think a number of Republicans would dislike some of the aspects of the TPP that center on issues of national sovereignty, so it's not like this has to be an especially partisan issue.