Earlier quoted context omitted.
hi snvzz, which server did you try it on? i tried few ipv6 servers and it was ok.
Try any DNS name which only has a AAAA record, e.g. ipv6.google.com, which results in “An unexpected error occurred.”
Alright, thanks!
SSH Check – public SSH server testing tool
71–80 of 125 posts
Re: SSH Check – public SSH server testing tool
#72Earlier quoted context omitted.
I disagree with Linus here -- there are hashes which are secure in all ways, and hashes which are broken, like SHA1. Why try to figure out where SHA1 is safe? Also, git's use of SHA1 is completely broken, it's just that no-one (that we know of) has chosen to spend the money required to make evil git repositories (you can't just take existing collisions and use them in git, you would have to go find git-specific ones)…
You'd have to find collisions that are of an identical length and still be useful (i.e. able to do something evil rather than just being a bunch of random data). The current techniques for creating collisions in SHA1 don't make it possible to find identical length collisions. So your statement that nobody has bothered to spend the money to create the collisions is not correct. Now if you want to say that nobody has s…
I think you are behind the times. There is already pairs of identical SHA1s, that do "interesting things", like these two PDFs by Google (and others): http://shattered.io/. Both 422435 bytes.
Re: SSH Check – public SSH server testing tool
#73There are a couple of strange things here. It lists oakley group 14 as insecure with no justification. That's a 2048 bit diffie hellman group and it should be totally fine. It also lists hmac-sha1 as problematic, although in hmac the weaknesses of sha1 are irrelevant. I'm not sure about the umac 64 bit block size. That should at least have some more info why it's considered problematic. Usually OpenSSH is pretty good…
Hi hannob, I'll re-check the classifications. Pretty sure you're right about the hmac-sha1 being still ok. Wrt oakley 14 and umac64 (and others) I'll try to add more detailed justifications. Thanks for your comment!
It's important to note that "HMAC-SHA-1" is an entirely different construction compared to SHA-1. It is a HMAC that happens to use SHA-1 internally, and it uses it in a way that means it does not yet share weaknesses with SHA-1 as a hash.
Of course, if you are writing something today, you should lean towards HMAC-SHA-256 or 512 as an extra buffer, but choosing to avoid HMAC-SHA-1 because it says "SHA-1" is not a valid reason.
Re: SSH Check – public SSH server testing tool
#74Great tool! Though I think it much safer to control these things client side, that way no matter what you're connecting to you know you're getting safe ciphers.
Re: SSH Check – public SSH server testing tool
#75It would be super-useful if it could give you something actionable for each issue if finds.
https://wiki.mozilla.org/Security/Guidelines/OpenSSH
While not exactly the solution you're looking for the Mozilla OpenSSH guidelines are quite better than the default sshd_config
Re: SSH Check – public SSH server testing tool
#76Is it just me or am I the only one who is a bit hesitant to submit the public IP/hostname to some random service on the web. I'm not trying to say that the creator of this has any ill intent, but I also don't know that they aren't cataloging addresses of potentially vulnerable ssh daemons. Anyway.. just to reiterate I'm not trying accuse you of anything OP. Very cool utility, nice work!
That's not something you need to worry about - if you have a vulnerable ssh daemon with a public IPv4 address, then it's already been indexed and you submitting / not submitting it won't change anything.
Scanning all standard ports of all addresses of all IPv4 internet is computationally feasible and is done by many parties. For example, https://www.shodan.io/ is one place that has done so and allows public searching of e.g. all public IPs returning a particular SSH version or having particular key exchange algorithms enabled.
Re: SSH Check – public SSH server testing tool
#77Earlier quoted context omitted.
You'd have to find collisions that are of an identical length and still be useful (i.e. able to do something evil rather than just being a bunch of random data). The current techniques for creating collisions in SHA1 don't make it possible to find identical length collisions. So your statement that nobody has bothered to spend the money to create the collisions is not correct. Now if you want to say that nobody has s…
I think you are behind the times. There is already pairs of identical SHA1s, that do "interesting things", like these two PDFs by Google (and others): http://shattered.io/ . Both 422435 bytes.
Or you aren't understanding the key statement of his comment
> You'd have to find collisions that are of an identical length and still be useful
Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible.
Git doesn't simply SHA-1 a file or the repo, it's more than that.
Linus:
> I haven't seen the attack yet, but git doesn't actually just hash the data, it does prepend a type/length field to it. That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header.
[https://stackoverflow.com/questions/42433126/how-does-the-ne...]
Re: SSH Check – public SSH server testing tool
#78It appear to have problems with newer chiphers. sshd[28670]: fatal: Unable to negotiate with 40.112.150.31 port 47286: no matching cipher found. Their offer: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,3des-cbc,twofish256-ctr,twofish192-ctr,twofish128-ctr,twofish256-cbc,twofish192-cbc,twofish128-cbc,twofish-cbc [preauth]
Hi andreaso, do you happen to have a list of encryption algs on your side? We don't support chacha20-poly1305 (yet) and afaik aes in gcm mode, but e.g. aes ctr are reliable so I find it strange these are not supported on your side.
That sshd only supports the chacha20-poly1305 cipher.
Perfectly fine with that, since I'm the only one logging into that server.
Re: SSH Check – public SSH server testing tool
#79Earlier quoted context omitted.
I think you are behind the times. There is already pairs of identical SHA1s, that do "interesting things", like these two PDFs by Google (and others): http://shattered.io/ . Both 422435 bytes.
Or you aren't understanding the key statement of his comment > You'd have to find collisions that are of an identical length and still be useful Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible. Git doesn't simply SHA-1 a file or the repo, it's more than that.…
> Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible.
This is incorrect. Git attaches a header to the blob before hashing, that much is true, but the technique used by Shattered to create colliding hashes can be used to create colliding Git hashes as well — you simply need to take the header into account in advance of doing the collision. (Which is why the particular PDF files released by Shattered do not hash to the same value in Git, but that does not mean that the technique used does not apply: it does.) At the time of shattered's release, I commented on this[1]; that comment goes a bit more into the paper's findings.
> Or you aren't understanding the key statement of his comment
Frankly, I thought the key statement of his original comment, as applicable to SSH, was, why use SHA1 when SHA256 exists, and doesn't have these issues? Take the route that requires you to not need to be a cryptographer to figure out if it'll work or not.
Re: SSH Check – public SSH server testing tool
#80Earlier quoted context omitted.
I think you are behind the times. There is already pairs of identical SHA1s, that do "interesting things", like these two PDFs by Google (and others): http://shattered.io/ . Both 422435 bytes.
Or you aren't understanding the key statement of his comment > You'd have to find collisions that are of an identical length and still be useful Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible. Git doesn't simply SHA-1 a file or the repo, it's more than that.…
> Or you aren't understanding the key statement of his comment
Sounds like it. People STOP referring to shattered.io, it is an entirely different issue.
Also, even if this was related... Can you really use shattered for MITM during key exchange which takes fraction of a second when that attack takes weeks of computation on a cluster of supercomputers??