robertgraham

The "Washington Game" is described the Society of Professional Journalists. https://www.spj.org/spj-ethics-committee-position-papers-ano...

Citing anonymous sources is not established ETHICAL practice, it's corruption of the system. The roll of the journalist is to get sources on the record, not let them evade accountability by hiding behind anonymity. Anonymity is something that should be RARELY granted, not routinely granted as some sort of "long established practice".

What is the justification for anonymity here? The anonymous source is oath bound not to reveal secrets, so what is so important here that justifies them violating their oath to comment on an ongoing investigation? That's what we are talking about, if they are not allowed to comment on an ongoing investigation, then it's a gross violation of their duty to do so. The journalist needs to question their motives for doing so.

We all know the answer here, that they actually aren't violating their duty. They aren't revealing some big secret like Watergate. They are instead doing an "official leak", avoiding accountability by hiding behind anonymity. Moreover, what the anonymous source reveals isn't any real facts here, but just more spin.

We can easily identify the fact that it's propaganda here by such comments about the SIM farms being within 35 miles of the UN. It's 35 miles to all of Manhattan. It's an absurd statement on its face.

This blogpost comments on Linus's latest tirade by reading the code.

For example, it explains the specific problem of technical debt on failing to mask of high order bits by casting the low part to (u16). Years from now, when this leads to a bug, you'll no longer be able to fix the macro because inevitable some code will by that time depend upon high order bits in the low part.

My guess is that your original SYN did not go to the target, but was redirected somewhere close by. I'd look at the TTL value in the IP header of your first SYN-ACK, and play with such things as traceroute.

Such redirection is often done on a specific port basis, so that trying to access different ports might produce a different result, such as a RST packet coming back from port 1234 with a different TTL than port 443.

There is so much cheating going with Internet routing that the TTL is usually the first thing I check, to make sure things are what they claim.

The first two answers are 8 and 0.

They are technically `undefined` according to the C standard, but are the behavior of every mainstream compiler. So much of the world's open-source code depends upon these that it's unlikely to change.

Using clang version 15.0, the first 2 produce no warning messages, even with -Wall -Wextra -pedantic. Conversely, the last 3 produce warning messages without any extra compiler flags.

The behavior of the first two examples are practically defined even if undefined according to the standard.

Now, when programming for embedded environments, like for 8-bit microcontrollers, all bets are off. But then you are using a quirky environment-specific compiler that needs a lot more hand-holding than just this. It's not going to compiler open-source libraries anyway.

I do know C. I knowingly write my code knowing that even though some things are technically undefined in the standard, that they are practically defined (and overwhelmingly so) for the platforms I target.

Nobody (yet) has mentioned Microsoft PWB - Microsoft's Programmers Workbench for their C compiler, around 1990. It's what all the Microsoft engineers themselves used when writing code for Windows, WinNT, OS/2, etc. It was essentially perfect for its time.

Ethernet doesn't use TCP/IP. Ethernet is it's own network. It has nothing to do with TCP/IP.

Other things use Ethernet. Routers, when connected to each other, often use a local Ethernet network to communicate.

Think of the TCP/IP Internet as it's own network, ignoring how routers physically talk to each other. Sometimes it's a directly link, a wire. Sometimes it's carrier pigeons. Sometimes it's WiFi. Sometimes it's Ethernet. Whatever it is, it's local to between the routers and does not extend outside that.

Well, you sort of demonstrate my point.

The writers the OSI Model wrote a specific blueprint, not an "observation of natural laws". When they said "session", they didn't mean the same things you conceive of. Instead, they meant a very specific problem of connecting dumb terminals to simplex links.

What you now call "sessions" is what OSI called "associations", and OSI defined them to be part of the "Application Layer".

I'm not sure you've even read the OSI Model. For example, the "Presentation Layer" is not defined to do the data format translation, but only to NEGOTIATE a common represenation. The actual data translation is still done in the Application.

This is the problem. People have not read and understood the entire model. They've not heard of "associations" and believe the OSI's use of "sessions" means anything they might call "session". They believe OSI was written as theory when it was not. They believe anything OSI terms they don't understand mean something else, mean some sort of timeless theory.

They are seduced by their own ignorance of the model.

I use RFC 791, the original Internet model.

RFC 1122 is a retconned version of the Internet model that tried to change terminology to fit OSI.

Yea, it's not about engineers constructing systems. I mean, engineers do frequently pretend their creations fit the OSI model, but they work backwards to make it appear to conform to orthodoxy.

The issue is about education. People teach the model, or some variation of it. It teaches misconceptsion, such as how Ethernet and the Internet are integrated in a single network stack rather than being independent networks. It leads to professionals in IT and cybersecurity who continue to hold this misconception.

It's wrong to think of them as different functions of the same network. Instead, they are differnet networks.

Ethernet and the Internet both provide the function of forwarding packets through a network to the target destination address. The MAC protocol and IP protocol provide the same theoretical function.

Where they differ is that Ethernet was designed to a be a local network, whereas the Internet is designed to be an internetwork. All it demand from local networks is that they get packets from one hop to the other. Ethernet does this for the Internet, but so do carrier pigeons.

The same is true for HTTP. Instead of thinking of it as a component of the network, think of it as something that rides independently on top of the network. In a hypothetical future whe we've replaced the Internet with some other technology, the web would still function.

You can't. Nobody knows what the session layer does. Most falsely believe that layer handles sessions.

I discuss this point several times. I claim the model is not useful, specifically because the layering abstraction for hte lower layers is a misconception rather than the truth.

For example, I describe how the OSI Model claims that layer #2 and #3 describe different functionality in the same network stack. I claim the opposite, how they describe roughly the same functionality in differnet networks.

Namely, both Ethernet and the Internet forward packets based upon addresses. The difference is that Ethernet does this locally while the Internet does this locally. Otherwise, the theoretical concept of packets, forwarding, and addresses are the same.

The book has an extensive section on history.

I claim that by 1981, the OSI Model was already obsolete and that it didn't fit well, that was not a good teaching tool, that it has done more to beffudle than enlighten students. The problem being is that if you learned according to the modle, you are not aware of what you misundertood.

Elsewhere in the text I describe how OSI chose a word at random, that they never meant by it what we now call "sessions". It could've been 'dialog layer' or 'interaction layer". I recommend they should've chosen "Intercourse Layer".

Contrast with my descriptions of the layers, especially in chapters 3, 7 and 8.

Well, as my footnote in the abstract says, it's swatting a fly with an anvil.

It's not about people who already deal with this, like Nanog or systems programmers. Whatever model they've started with, they've developed a better one in their heads based upon their own expertise and experience.

It's about educators who continue to teach out-dated concepts.

Take Presentation Layer #6 as an example. It was created because in the 1970s, every computer model had a different character-set, and every terminal model different command-codes. It was therefore assumed that translating among these different formats would be a property of the network, that a fundamental step would be negotiating some common representation, like it is with FTP and Telnet.

This is no longer true today. Everything's Unicode. A PDF file on an EBDIC IBM mainframe is still encoded as UTF-8. Data representation is a property of the DATA not a property of the NETWORK. But people are slow to adapting to this paradigm shift.

As for "layering violations", I propose an alternative model where there are no layering violations. If real world conflicts with your model, the model needs updating.

I have no clue what point the author's trying to make here

You mean, you don't know the agenda. The "point" was data, namely: - the Washington game that leads to unreliable journalism - the fact that all Huawei's competitors have the same law enforcement backdoors, the same support contracts, and there's no evidence or even accusation that Huawei is doing anything different - my own personal experience watching Huawei support engineers using their "backdoor" "sidedoor" "frontdoor" access to gain intelligence information.

implying it's reporting is inaccurate

Unreliable, not really inaccurate. It's clearly bad journalism violating clearly expressed ethical standards. That doesn't mean it's wrong, it doesn't mean the government official's accusations are false. It instead means that we can't rely upon them.

straw-man argument that all telco manufacturers/operators do similar things for law enforcement so we shouldn't be concerned about Huawei's practices

I'm not sure you read the article. I make it clear that we should be concerned about Huawei even if their hardware, software, and support access are no different than any other vendors, because the Chinese government can lean on them in ways democratic governments cannot lean on their own vendors.

comes off as blatant astroturfing

One of us does not understand "astroturfing". This is clearly an anti-Huawei piece that nonetheless tries to understand things from Huawei's point of view. I haven't worked with Huawei's engineers, I was working on a mobile companies systems when I saw Hauewei's support people log in via their VPN and gather national intelligence information.

The point is that everything can be true: Huawei can in fact be no different any competitor, doing at least as good a job preventing backdoors, and yet still be a national security threat due to backdoors. I believe it's good policy to forbid Huawei equipment in 5G deployments even if I doubt they have any special technical backdoors.

It's an absurd point.

ZCash was built upon the Bitcoin codebase. This inherits a lot of bad decisions. Moral purity, demanding they start over again from scratch, just isn't practical.

The bug in question could have been solved had the simply compiled with minimal static analysis -- by which I mean -Wall.

C/C++ is memory safe if you turn on dynamic checking. Sure, it's twice as slow as C/C++, but still tons faster than nonsense languages like Ocaml or Haskell.

Yea, your startup failed long ago. You are just throwing good money after bad.

Here's how a business model works: you try a business model. If it works, great. If it doesn't, move on and try the next business model. You are either growing, dieing, or the zombie of living death. If it's the last two, get out now.

If you are a skilled person, then you can always get another job elsewhere, especially now that you've got "startup experience" on your resume. Conversely, if you aren't skilled, then that's probably causing your startup's failure, and that's not going to change.

Being overly optimistic is great when starting a company. You have to believe, against all odds, that you are going to succeed. But optimism death AFTER starting up, hanging on hoping things will change when they won't.

Growing companies have a chance of success. Dieing companies really don't. Zombie companies are even worse. Get out.

'cause I'm a Windows user who don't know the advanced flags of Unix command-line tools

I build stacks that are highly customized for the target solution and are impractical for general purpose use.

A good general purpose stack is the 6windgate stack. I know nothing about it personally, but I know that a lot of people do use it successfully.

The Linux TCP stack is NOT fast. My DNS server can respond to DNS queries faster than the simplest of in-kernel echo servers (like ICMP ping or UDP port 7 echo). That's with the entire DNS overhead of parsing the DNS protocol, looking up the name in a very large database (like the .com zone), doing compression, and generating a response.

The upshot is this: going through the Linux stack, a DNS server is limited to around 2 million queries/second. Using a custom user-mode stack, it can achieve 10 million queries per second.

ah, so you agree that the content of the article is good -- you just don't like the writer

I've long had experience with: exploits working for the wrong reason, and also the reverse, failing for the wrong reason.

For example, way back in the day before ISS bought my company, somebody claimed their IDS was vulnerable to an IMAP evasion. They actually weren't, but that specific test triggered a wholly separate (and much worse) bug that made it look like it was evadable. I laughed and laughed.

This has been there for nearly the entire history of Bash, like 2 decades.

People are good at convincing themselves there is no problem. Vendors are good at convincing people there is no problem. The demonstration has to hit them over the head with the obviousness of the exploit. If the private-key pops up automatically, and a sensor didn't detect it, they have to believe. Otherwise, when the sensor doesn't fire, they'll believe that the exploit is at fault.

Because Snort's signatures can't detect 'heartleech'.

But most other IDSs can, such as Bro.

Unless there is a tool that demonstrates this, people won't believe that there is a difference between Snort and Bro, because existing tools don't show a difference.

You still have to be in a spot to snoop. If you are a random hacker wanting to snoop on a Russian bank, once you get their private key, you have to now tap into the network. This is unlikely to be within your ability. You might fly to Russia and sit in cybercafe's open to catch people on the open WiFi, but it's not something that's easy.

On the other hand, as the above comment says, you can use heartbleed in other ways, such as catching people's cookies from memory, then insert those cookies into your own browser and hijack their connection.

Among the things I'm famous for is having written a proxy server you can aim your browser through in order to do cookie hijacking: https://github.com/robertdavidgraham/hamster/

Nobody is writing articles at Neel Mehta, the guy who discovered the bug. They should, he's a god.

Yup.

Getting a private key using the extent simple scrypts is quite complicated, with lots of difficult steps. This is no barrier to teenage kids, who has lots of time on their hands that can play around until they get things right.

As a defender, however, you don't have that much time. For you, it's really easy. If you have a server, and want to know if the private key is visible, just download the Windows heartleech binary from github, run it against a server, walk away for 10 hours, and then come back to see if it's gotten the key.

In short, as you say, a tool that effortlessly prints the private key of a production server is worth a bazillion blogposts and security advisories. Code or GTFO, IMO :)