The curious case of the Raspberry Pi in the network closet (2019) • Hacker News Board

Re: The curious case of the Raspberry Pi in the network closet (2019)

#221

Post by hamburglar » Mon, Jan 17, 2022, 10:09 PM UTC

teddyh wrote: post #128

natpalmer1776 wrote: post #120

Earlier quoted context omitted.

While I'm sure I could configure this on a system, the level of understanding required to actually create it honestly is fantastic. Is this something you created yourself, or was it a community project?

Initial idea and C++ implementation (using TLS with X.509 certificates and explicit UDP broadcasts) was done in 2007 by another person. Redesign of the protocol (to TLS with OpenPGP keys¹ and DNS Service Discovery²), and re-implementation in Python and C, I did in collaboration with that person. In addition to ongoing maintenance, the relatively recent switch from TLS with OpenPGP keys to TLS with Raw Public Keys³ wa…

Looks like a neat project but the intro/faq should probably be a bit more self-critical to point out weaknesses. The “nope, it’s protected by TLS” answers ignore the fact that anyone attacking this could also have attacked the PKI. If someone gets the client cert and key, they can probably fake the request to get the decryption password. I’m assuming that client key isn’t protected by a password, since then that would be the thing a user has to provide at boot time. And what about the vector where someone attacks the CA that issued the certs? Where is that stored? Can fake roots be injected by someone in possession of both machines? This may be moot if you are using self-signed certs, but of course those introduce their own management issues.

Also, I don’t really see any discussion of availability concerns. This is a system with a pretty gnarly fail-closed kill switch that could happen with a simple network outage. That doesn’t really seem to be acknowledged and there’s no discussion of the inherent balance between security and availability. You really need to be able to guarantee a certain level of availability or things basically self-destruct. Presumably there’s a mechanism that allows a self-destructed pair or cluster of these mandros’d servers to go back to a normal operating mode?

Anyway, I don’t mean to be too critical. It’s a really cool project. A little Byzantine but with a stated reason for that. Would just like to see more focus on the weaknesses and potential critical operational issues. A section called “reasons you may not want to use this” that is very up front about those seems appropriate.

Re: The curious case of the Raspberry Pi in the network closet (2019)

#222

Post by SolarNet » Mon, Jan 17, 2022, 10:10 PM UTC

dehrmann wrote: post #202

mbreese wrote: post #172

Earlier quoted context omitted.

The person who has the device never agreed to that license…

Finding a book on a sidewalk doesn't mean you can scan it and legally distribute it.

Yes but if said book was used in the commission of a crime there is a certain level where it doesn't matter.

Don't plug shit into private networks unless you want it reverse engineered. This falls under the fair use exceptions (learning what software is doing / was doing to your network).

The copyright holder can take it up with whoever they licensed it to, there is a reason a lot of them read "not to be used in the commission of a crime".

Re: The curious case of the Raspberry Pi in the network closet (2019)

#223

Post by tech-no-logical » Mon, Jan 17, 2022, 10:15 PM UTC

magicalhippo wrote: post #23

Reminds me of this[1] good old quote from the IRC days hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. [1]: http://bash.org/?5273

Re: The curious case of the Raspberry Pi in the network closet (2019)

#224

Post by PragmaticPulp » Mon, Jan 17, 2022, 10:23 PM UTC

ChuckNorris89 wrote: post #190

PragmaticPulp wrote: post #140

Earlier quoted context omitted.

> Wow, imagine hating your boss so much you go to so much creative and illegal lengths (that can backfire against you) to track him, instead of using same skills legally to finding a better job. I’ve mentored a lot of juniors. It’s not uncommon for young people, especially those with less developed social skills, to have an undeserved fear of their boss or anyone else with authority. It’s common with young people who…

>I’ve mentored a lot of juniors. It’s not uncommon for young people, especially those with less developed social skills. Sure, but even as a junior employee, we're still talking about mature adults here, not kindergarten kiddies, who can vote, pay taxes and are held accountable for their actions in front of the law, so they should be aware that deliberately backdooring their employer so that they can surveillance the…

> Sure, but even as a junior employee, we're still talking about mature adults here

It’s a wider range than you’d think. Juniors range from seasoned employees who have had various jobs over the years to completely green employees who have never had to work a day in their lives. The latter group can allow a lot of people to avoid dealing with their problems and maturing for a long time.

> Yeah, I get that, but how is this in excuse for hacking your employer/boss?

It’s not, and I never said it was. I was only replying to the insistence that the boss must be a terrible person.

This behavior is never acceptable.

Re: The curious case of the Raspberry Pi in the network closet (2019)

#225

Post by teddyh » Mon, Jan 17, 2022, 10:24 PM UTC

hamburglar wrote: post #221

teddyh wrote: post #128

Earlier quoted context omitted.

Initial idea and C++ implementation (using TLS with X.509 certificates and explicit UDP broadcasts) was done in 2007 by another person. Redesign of the protocol (to TLS with OpenPGP keys¹ and DNS Service Discovery²), and re-implementation in Python and C, I did in collaboration with that person. In addition to ongoing maintenance, the relatively recent switch from TLS with OpenPGP keys to TLS with Raw Public Keys³ wa…

Looks like a neat project but the intro/faq should probably be a bit more self-critical to point out weaknesses. The “nope, it’s protected by TLS” answers ignore the fact that anyone attacking this could also have attacked the PKI. If someone gets the client cert and key, they can probably fake the request to get the decryption password. I’m assuming that client key isn’t protected by a password, since then that woul…

> If someone gets the client cert and key, they can probably fake the request to get the decryption password.

Yes, that is a weakness, which is openly addressed in the FAQ: https://www.recompile.se/mandos/man/intro.8mandos#quick TLDR: It only works if an attacker is pretty quick about it. See also here: https://www.recompile.se/mandos/man/intro.8mandos#security

> And what about the vector where someone attacks the CA that issued the certs?

There is no CA involved, nor any X.509 keys. The keys used in TLS are ed25519 raw keys, and the server has a list of, and checks, individual key fingerprints.

> This may be moot if you are using self-signed certs, but of course those introduce their own management issues.

Yes, you have to generate and transport keys out-of-band (i.e. by hand) as part of the initial setup. The instructions on exactly how to do this are shown as part of installation and configuration.

> a pretty gnarly fail-closed kill switch

That’s a feature. A security system should fail closed.

> Presumably there’s a mechanism that allows a self-destructed pair or cluster of these [mandos]’d servers to go back to a normal operating mode?

Yes. You either type in a password on the console on one of the servers, or use a dropbear to ssh in remotely to do it.

> A section called “reasons you may not want to use this” that is very up front about those seems appropriate.

The project is mostly intended for those people who have already decided that full-disk encryption is a requirement, and Mandos is meant to alleviate some of the pain which they have already accepted. But sure, I see your point.

Re: The curious case of the Raspberry Pi in the network closet (2019)

#226

Post by imwillofficial » Mon, Jan 17, 2022, 10:25 PM UTC

suifbwish wrote: post #171

imwillofficial wrote: post #94

Earlier quoted context omitted.

This is a silly take. People and orgs have a million reasons why their cables might be unlabeled. Shame on you for binary thinking without considering real world confounding factors.

What I am hearing is that is that it is not practical to expect network admins to be in control of their networks and sub-sequentially it is not practical to ensure no malicious devices are plugged into enterprise networks. Just because it’s difficult to do doesn’t mean it shouldn’t be done.

Suif, you have a lot to learn my friend. First is speaking in such absolutes.

The more senior I get, the more I realize there are often a multitude of reasons things are the way they are, and many times those are valid reasons, when seeing something that is broken.

Taking a beat before pontificating and making a fool of yourself will save a ton of heartache in your career.

When you see something so broken, ask yourself why? Then ask somebody else. Some highlights from my career:

1) Last guy got cancer in the middle of a build.

2) Last guy worked his way up from one man help desk to Linux guru over 15 years all on his own, but was so busy putting out fires, he never had the chance to improve things.

3) Project started out as a proof of concept and was intended to be torn down.

4) Due to government contracts, the system has to be maintained exactly as delivered, no labels even allowed, and obviously no IT staff(?!) To make spreadsheets. Everything was paper notes by operators.

5) Pure laziness and incompetence as you alluded to.

All this to say, more often than not there is a good reason something is fucked up, finding out why may help you fix it (like in the case of politics, budget issues, firefighting, priorities, etc..)

Re: The curious case of the Raspberry Pi in the network closet (2019)

#227

Post by imwillofficial » Mon, Jan 17, 2022, 10:28 PM UTC

vel0city wrote: post #118

imwillofficial wrote: post #96

Earlier quoted context omitted.

Explain to me exactly how wireless keyboards are “ inherently bad ideas”, and not something that can be fixed with a robust technical solution?

Some wireless keyboards don't bother with any kind of protection to the data stream between the keyboard and the wireless receiver. That's the most obvious instance of bad keyboards. However, these days most wireless keyboards do use some kind of encryption on the pairing between the keyboard and the receiver, so that is a bit of a moot point. Even if the data stream itself is encrypted there's still a little bit of…

These problems could be fixed with a robust technical solution.

Re: The curious case of the Raspberry Pi in the network closet (2019)

#228

Post by Jolter » Mon, Jan 17, 2022, 10:32 PM UTC

amelius wrote: post #217

Heard a story about some ethernet device cemented into a wall, perhaps on HN. Good luck finding that ...

Once upon a time when Zigbee was the latest hype, a friend worked on a project to cast cheap hygrometer sensors into concrete and have them report via a mesh network. Apparently sensors were predicted to be cheaper than to have an engineer walk the site taking readings to ensure it’s ok to start covering it up.

Re: The curious case of the Raspberry Pi in the network closet (2019)

#229

Post by folmar » Mon, Jan 17, 2022, 10:37 PM UTC

BlueTemplar wrote: post #212

jokoon wrote: post #13

I'm rather curious, why can't the RPi have soldered flash memory? How much would it cost to add 2, 4, or 8GB of flash memory on it? Because I would gladly pay for a Rpi with such memory if it added 10 dollars. I'm suspecting it would require for them to make a new SOC, breaking compability?

Thus tripling the cost of the cheapest Pi - which costs $5.

This is a marketing price, if you buy in bulk it costs $15.

Re: The curious case of the Raspberry Pi in the network closet (2019)

#230

Post by PragmaticPulp » Mon, Jan 17, 2022, 10:45 PM UTC

eternityforest wrote: post #199

PragmaticPulp wrote: post #140

Earlier quoted context omitted.

> Wow, imagine hating your boss so much you go to so much creative and illegal lengths (that can backfire against you) to track him, instead of using same skills legally to finding a better job. I’ve mentored a lot of juniors. It’s not uncommon for young people, especially those with less developed social skills, to have an undeserved fear of their boss or anyone else with authority. It’s common with young people who…

Doesn't anxiety tend to not make you want to sprinkle boxes of malware in network closets? Like, I would be absolutely terrified to even accidentally overhear someone talking about this and possibly be dragged into it that way.

The author of this piece didn't work at the company. It sounds like the company wasn't really full of technical people. The perpetrator probably thought they were so much smarter than everyone else that they'd never be caught.