Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Falsehoods programmers believe about networks

blog.erratasec.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Falsehoods programmers believe about networks

#11

Post by chris_wot »

developer2 wrote: post #6
rvense wrote: post #4

It'd be great if someone wrote three lines explaining why one would believe each of those, why it's wrong, and why that's important.

And by "it'd be great", what you really mean is "the article is completely useless without them". Half of the items are "no shit"; another 20% is "huh?", and the remaining are "that might be interesting to learn more about - but with no additional information, I don't even have enough keywords to Google to find out more".

You aren't using Google effectively enough then.

Re: Falsehoods programmers believe about networks

#12

Post by dllthomas »

Vendan wrote: post #7
rvense wrote: post #4

It'd be great if someone wrote three lines explaining why one would believe each of those, why it's wrong, and why that's important.

I tried to write up a little about the ones that I know something about, here it is: Data on the network cannot be altered. False, if something goes through another device, it can be altered. Important because, well, man in the middle. Encrypted data on the network cannot be altered. Same as the above. Harder, but still doable Data cannot be accidentally corrupted, because TCP has checksums and Ethernet has CRCs This…

> TCP will reorder them back to the original order for you.

And of course even that's only true within a single connection.

Re: Falsehoods programmers believe about networks

#13

Post by dllthomas »

Vendan wrote: post #7
rvense wrote: post #4

It'd be great if someone wrote three lines explaining why one would believe each of those, why it's wrong, and why that's important.

I tried to write up a little about the ones that I know something about, here it is: Data on the network cannot be altered. False, if something goes through another device, it can be altered. Important because, well, man in the middle. Encrypted data on the network cannot be altered. Same as the above. Harder, but still doable Data cannot be accidentally corrupted, because TCP has checksums and Ethernet has CRCs This…

> The only thing that cares at the application layer is the application code,

True, but...

> it can just say "everything is little endian" and be done with it.

... doesn't quite follow. If you're blitting integers directly, your code will break on either a big- or little-endian boxes. Better to pick a standard encoding and always serialize/deserialize properly whatever that means. That standard encoding may be little-endian (maybe better than big-endian - such systems are overwhelmingly more common on the desktop/server) or may be some packed representation. But ideally you could change the representation without changing application code other than the serialization/deserialization itself (which may well live in a library).

Re: Falsehoods programmers believe about networks

#14

Post by dllthomas »

Somasis wrote: post #9
rvense wrote: post #4

It'd be great if someone wrote three lines explaining why one would believe each of those, why it's wrong, and why that's important.

This is effectively the problem with all of these "things programmers assume" articles: they give no solutions and effectively just moan about possible problems.

"Things people writing Things Programmers Assume articles assume..."

Re: Falsehoods programmers believe about networks

#15

Post by crottypeter »

Vendan wrote: post #7
rvense wrote: post #4

It'd be great if someone wrote three lines explaining why one would believe each of those, why it's wrong, and why that's important.

I tried to write up a little about the ones that I know something about, here it is: Data on the network cannot be altered. False, if something goes through another device, it can be altered. Important because, well, man in the middle. Encrypted data on the network cannot be altered. Same as the above. Harder, but still doable Data cannot be accidentally corrupted, because TCP has checksums and Ethernet has CRCs This…

Also : Browser history is synced via 'the cloud'

>> It's an internal web app -- outsiders won't be able to discover where it is (@biosshadow)

>if this is about a "exposed under an obscure name", the tools like fierce can probe for it. If it's exposed to the internet at all, consider it under attack at all times.

Re: Falsehoods programmers believe about networks

#16

Post by thecatspaw »

chris_wot wrote: post #11
developer2 wrote: post #6

Earlier quoted context omitted.

And by "it'd be great", what you really mean is "the article is completely useless without them". Half of the items are "no shit"; another 20% is "huh?", and the remaining are "that might be interesting to learn more about - but with no additional information, I don't even have enough keywords to Google to find out more".

You aren't using Google effectively enough then.

>It's an internal web app -- outsiders won't be able to discover where it is (@biosshadow)

explain

Re: Falsehoods programmers believe about networks

#17

Post by TheRealEdAbbey »

Somasis wrote: post #9
rvense wrote: post #4

It'd be great if someone wrote three lines explaining why one would believe each of those, why it's wrong, and why that's important.

This is effectively the problem with all of these "things programmers assume" articles: they give no solutions and effectively just moan about possible problems.

They honestly read like clickbait: "10 myths programmers always assume - #6 will SHOCK you!"

Re: Falsehoods programmers believe about networks

#18

Post by chris_wot »

thecatspaw wrote: post #16
chris_wot wrote: post #11

Earlier quoted context omitted.

You aren't using Google effectively enough then.

>It's an internal web app -- outsiders won't be able to discover where it is (@biosshadow) explain

If it has a public IP address, it can be discovered.

Re: Falsehoods programmers believe about networks

#19

Post by asmithmd1 »

One that has bitten me:

"ACKs come from an end node"

Cellular carriers will ACK a packet destined for a device on their network before they have actually delivered it if they have the device registered and are confident they can deliver the packet "soon." I have seen packets happily being ACKed that are destined for a device that I just powered down. About a minute later the carrier starts telling the truth, but now you have no idea what actually got through to your device.

Re: Falsehoods programmers believe about networks

#20

Post by angry_octet »

Also:

- MAC addresses are unique.

- LANs won't be bridged.

- Spanning tree will converge quickly.

- Quickly enough that it will beat BIOS getting to DHCP for netbooting.

- There will only be one circuit in the network so you can disable spanning tree.

- The path MTU will be at least 1500 (or 9000, or x).

- Path MTU discovery will work.

- Packets with DF bit set won't be fragmented.

- ICMP won't be dropped.

- Network circuits will be the same path in both directions.

- There will be one NIC / a default route.

- The domain name 'localhost' will always resolve to localhost, or 127.0.0.1.

- A DNS responder exists on the network.

- It is a good idea to try to resolve IP addresses as names.

- A device will use IPv4 by default (some systems opportunistically look for A and AAAA addresses and try both).

- All networks have a path to the internet.

- There will be no proxy required, or

- The proxy won't require a login, or

- The proxy credentials won't have a backslash.

I'm diverging higher up the stack at this point so I'll stop.

Post reply on HN