HN user

nuxi7

228 karma

[ my public key: https://keybase.io/nuxi; my proof: https://keybase.io/nuxi/sigs/yRrZ1860HBY-rHJUyQhKbNaUxje5E1VAVWJnOpJp-bI ]

Posts0
Comments58
View on HN
No posts found.

For the curious, the need to change the malloc behavior is not hypothetical:

https://sourceware.org/bugzilla/show_bug.cgi?id=6527

Basically for many years now glibc has been knowingly doing the wrong thing just to keep malloc_set_state/malloc_get_state working. Which as far as anyone knows, is used only by emacs. Keeping this interface alive for the sole benefit of an emacs optimization when it is blocking the fixes for fairly serious bugs is a pretty big bar to meet for justification.

In the end this is largely a non-issue as an Emacs developer noted that their configure script probes for the special glibc malloc API and if it doesn't exist then emacs will use its own malloc implementation. The conclusion is that once the glibc devs get their changes up, everyone can meet up again to make sure existing emacs binaries still run and that the API detection in the emacs configure script works right.

So props to Paul Eggert for being the only sane man in the room and pointing out that the drama was all for nothing.

The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the documentation. The user of the distributed tarball is fully capable of re-running these steps, but they have become optional.

This is a fact often forgotten when projects switch to github and just start using the automated release tarballs github will make from the repo.

You've hit on a fine point I often make about how the term "security bug" is used.

I would call this a bug fix since someone has found what is probably an unintended behavior in the cubic algorithm. The cubic algorithm itself though would be a feature improving on the original tcp algorithm (nagle, if I remember right)

Same reason unix systems typically did the same with theirs (albeit on port 111)

Its not very useful if other machines can't talk to it.

Keep in mind, the decision to do this in Windows happened back when home computers were on dialup. (Even RFC 1918 and NAT were young at the time) The real question is why didn't Windows have a firewall that blocked it by default and the answer is that it has.... since XP SP2 was released in 2004.

Since marketing and selling jamming devices is illegal, I would like to know what the FCC is going to do about the supply chain. We know these are all using well known advertised features of enterprise wireless gear. Are they working on a consent decree with Cisco/Aruba/etc to stop including this feature? Or are they going to play whack-a-mole with end users for the next decade?

[dead] 11 years ago

pretty sure it normally goes on your profile page.

dude, es6 is way too mainstream for cutting edge web programming. If you're not using es7 already you might as well still be using table layouts

Logjam TLS attack 11 years ago

Because this isn't really an attack per se. There are some interesting things in the paper, but really this is just low grade crypto being tolerated for far too long in the name of compatibility.

I finally found the Mozilla bug entry for this, they've known of it since 2010 when they raised the minimums to 512-bit DH groups.

https://bugzilla.mozilla.org/show_bug.cgi?id=587407

Logjam TLS attack 11 years ago

That parameter is only for SSHv1 and if you have SSHv1 enabled you've already lost.

What they are refering to is the Key Exchange method named "diffie-hellman-group1-sha1" which uses a 1024-bit DH group. You can disable this with use of the KexAlgorithms parameter. Starting with OpenSSH 6.6 it is already disabled on the server side, but still allowed with the client. There are severe interoperability problems with embedded devices if disabled.

Totally This ^

This is a key you get re-signed every 1-3 years. You don't need it to last 10 years, you need it to last maybe a year longer than your SSL cert is actually good for. (Assuming your site is setup to have all the browsers do PFS)

Its probably just scans from zmap. Complaining about zmap scans is about on the level of complaining about ssllabs.com scanning your box.

https://zmap.io/

It could be a student in the dorms who discovered metasploit though. Or someone in the computer lab who has a tool that doesn't need root. (or who rooted the lab computer)

I'm curious why you bother with (non-EC) DHE at all? Its an interoperability nightmare thanks to the lack of DH param size negotiation in the TLS handshake and all the clients that work with the larger (larger than 1024-bit) DH params also do ECDHE. And at the end of the day, there aren't really that many DHE capable clients that won't do ECDHE. For interoperability reasons I prefer to just keep DHE off and let those rare clients use non-PFS suites.

PS: you're my hero for making this page to begin with. I often direct people to it who ask about SSL settings. Even if I have my own tweaks to the list. Its useful for more than just webservers too.

Non-EC DHE is basically dead. The param size isn't part of the TLS handshake and so using a larger size actually breaks some clients that only do 1024-bit DH params. At the end of the day, almost all the clients that support larger DH param sizes also support ECDHE, which is faster anyway. You might as well not bother and just keep a few non-PFS ciphers for those clients to avoid interoperability problems.

Bonus trivia: ssh-dss (SSH DSA keys) has vaguely similar problem, which they considered fixing but decided instead to simply not repeat the mistakes when writing the SSH ECDSA spec. This is why ssh-dss keys are effectively limited to 1024-bit.

Linux 4.0-rc1 out 11 years ago

The switch from 2.4 to 2.6 had a lot of changes and a lot of programs needed to check the version to see which behavior to use. There are two ways to do that shown below in psuedo-python. This first way has no trouble with 3.x versions.

if kernel_version.startswith('2.4.'): DO_A else: DO_B

On the other hand, if you check for 2.6 instead of checking for 2.4... Well when it encounters 3.0 the code falls back to 2.4 behavior.

if kernel_version.startswith('2.6.'): DO_B else: DO_A

Sadly a number of binary only RAID tools don't really get updated much and have these problems. There is a program in util-linux named uname26 that you can run these tools under which gives them the 2.6.40+ version numbers.

This is just one of those tricks operating systems have to resort to from time to time, its like how Microsoft is skipping Windows 9 because of how many programs execute version.startswith('Windows 9') and assuming that means Win95/Win98.

Article is misleading, The librarian of congress is permitted to make exemptions from the DMCA every few years. After exempting cell phone unlocking twice, he declined to do so again on the grounds that these exemptions were not supposed to be used to create permanent public policy.

Congress and the President have now exempted unlocking with a new law, which is exactly what the librarian of congress said should be done if they want to create permanent public policy for that exemption. So they did not overtune a decision of his, he was in support of this, he just insisted it be done properly.