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.
The site also seems to flag RSA host keys. Using SHA1 in this case shouldn't be a security issue since the hash is calculated as SHA1(SHA2(x)) and you would need to break SHA2 as well. [1]
Here is my problem with this statement: SHA-1 can be used in different configurations for different applications. Some are secure, some are not.
People making these blanket statement very clearly demonstrate that they don't understand security and cryptography. Do you really want to use a security tool written by such people?
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 spent the time to find a technique to produce identically sized collisions, that would be correct. But that's far from trivial and we don't know that such a technique is guaranteed to exist.
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.
> 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.
> 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??
Seems fairly good - I would consider going 25519-only if you have compatible clients for kex and auth.
Some of their concerns with SSH agent forwarding are good too - but make me wonder if writing some little GUI that would have you allow or deny authentication requests would solve the problem.
If I see some "weak" or "insecure" tags, what can I do about it? I have no idea how to disable MAC, key-exchange, and encryption algorithms used by the server I control. I had thought that just using SSH was "enough"
More importantly, if I do disable the insecure stuff, what will it break ?
> If I see some "weak" or "insecure" tags, what can I do about it? I have no idea how to disable MAC, key-exchange, and encryption algorithms used by the server I control. I had thought that just using SSH was "enough"
For the most part it is, many of the things they're labeling as "weak" is not stuff that's likely to get you exploited today, but stuff that might at some point in the future - attacks only get better. Not necessarily things that are completely broken, just weak by today's standards.
> More importantly, if I do disable the insecure stuff, what will it break ?
Older clients mostly. Many phone apps for example don't have recent SSH implementations that support newer cryptography.
A suggestion: add simulated handshakes for various versions of OpenSSH and PuTTY to indicate which cipher/auth/kex algorithm they would negotiate with their default settings (ala the SSL Labs scanner).
Is 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.
Yes, non-standard ports transfer it to the domain of either somewhat targeted scan or serious effort - scanning all ports of all IPv4 requires many machines and/or many weeks, so that's not available to everyone. However, I'd still expect multiple organizations to keep an up-to-date scan of all public facing ports worldwide; it's impractical to do it for fun, but if have a need and some budget, it seems doable.
If they wanted to find vulnerable ssh daemons it would be much faster and easier to scan the web than wait for people to enter their details here.
Or to put it another way: if you're worried that your SSH is vulnerable, fix it. Don't rely on not typing it into a website, because people will find it regardless.
In my experience, if you have an SSH port accessible from the internet, it has been probed today by a few Chinese/Russian IPs. Unless my raspberry pi home server is somehow a high value intelligence target...
In my experience a SSH service on a random, non-standard port gets surprisingly few probes. I look after several machines and I see less than one attempt per year (versus hundreds per day for port 22). I have yet to see somebody probe a SSH that listens on IPv6-only.
No, the best solution is to only allow login by SSH keys. No passwords => brute-forcing is impossible. So your threat model for someone gaining access no longer includes someone using weak passwords.
- if the server is public already then black hats can simply probe your networks (IPv4 is not that big) and find the servers by themselves. The odds are that hackers are probably not interested in your company anyway.
- there are people who don't care about security of their servers (or rather are lazy / naive) and might find this service useful. Even if we were black hats it would at last alarm them that something is wrong. If they ignore the warnings - well - god help them.
You're getting a lot of responses along the lines of: "Well if it's on the public internet it's already being indexed and scanned already, so there's no harm submitting a single IP address / hostname." Whoever thinks this is relevant: Please post your personal server's IP address here.
My phone number is 10 digits. It can easily be enumerated. I'm still not posting it in a public forum or submitting it to an unknown web site.
Sure thing. I have two boxes that run sshd exposed to the internet: 69.164.221.163 and 45.79.85.20. sshd runs on port 2020 now; I was running it on port 22 before but I got so many failed login attempts that it was actually causing noticable load on the system (something like average 10% CPU usage just for sshd).
I still get a couple hundred failed login attempts every day. Reasonably strong passwords and fail2ban mean that it's nbd.
Also, my phone number is on my website (it's 320 584 9293) and most of the spam calls I get are through whois, not the fact that there's a tel: URL out there pointing at it.
There's a significant difference - posting this information here is saying that x.y.z.w is my server, and that has a privacy concern, just as saying that my (or your) phone number is 1234567890.
Anonymously submitting that x.y.z.w is a server running ssh, on the other hand, doesn't provide anything beyond what's already publicly known.
Also, your phone number is not easily enumerated. Scanning even a small range of phone numbers (i.e. attempting a connection to see if they're valid) takes significant time and effort. Finding all open standard ssh ports on the whole internet, on the other hand, can be done in minutes with a good enough connection.
I tried entering my personal server's hostname and port number but it timed out trying to connect. Then I remembered that I configured my server's firewall to only allows SSH connections from my home ISP or work IP address.
I too would prefer to use a standalone tool that I could use for testing my SSH configuration without having to temporarily disable those firewall rules.
Well, yes and no - I can see the argument that it might be nice to test them locally before you expose them to the world (and I suppose you might also have them on a private LAN permanently), but otherwise, they will be tested, by someone, and soon...
But the fewer people "test" it, apart from me, the better.
This is akin to putting your email address all over the internet. If you do that, you're going to get lots of spam. If you are more careful about who you give it to, you'll get less.
It's clearly a win to keep both email addresses and ssh server addresses as private as possible.
The difference between IP and email adresses is that one is trivially enumerated, the other is not.
Any internet-facing server that responds on port 22 will get several (up to hundreds) of failed login attempts per day. Just install something like fail2ban and watch your logs.
When was the last time you looked at your SSH logs for public machines? Your public IP is just that, public. Anyone can scan it, and it most certainly gets hit by many scanners a day.
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.
Great 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.
I know many people keep an encrypted copy in various cloud or email accounts. Then all you would need is the encryption password and internet access to download the application to decrypt.
A USB smart card like a Yubikey NEO or 4 might be useful. Keys are securly stored in the card and never leave it.
Alternatively, a USB smart card reader and a normal smart card, but this is physically larger.
My main focus is ongoing alerting of changes to HTTPS configs rather than just a one off check. So you can be confident that everything is up to your spec or know as soon as something isn't.
Because we'll know your setup we can also alert you to things you specifically should be aware of - for instance a browser policy change that would affect user experience due to your certificates not meeting the browser policy etc.
Feel free to mail me if you'd like more info! (email in profile.)
(PS. YC Startup School's virtual demo day is tomorrow if you're interested! All the startups that completed the course are posting a short demo video.)
Well then let me thank you again :) Very slick UI, signed up in seconds, set myself up in under a minute.
What are your plans with it? Just leaving a free service running or do you want to add paid plans as well? (and if not, I would recommend setting up at least a "Support" plan of some kind; it sends a strong signal)
I have no set plan yet (the site is 1yr old)... SSLPing monitors almost 6000 servers daily, 250+ users... so maybe I'll follow your advice with some kind of support plan (I was thinking of donations)
Common piece of feedback I have seen in many donation-driven software projects:
Don't do donations. Do a support plan; even one as basic as "priority replies to emails". If a company wants to use your product, even if they want to pay, it's very hard to justify a donation whereas a support plan is far more readily bought.
It'd be useful to know what this is likely to break, AFAIK I sshd doesn't log what ciphers people used, like Apache can do. A caniuse.com for SSH would be useful.
It's quite probably because of compatibility with the older clients. Unfortunately you can't simply use only the safest algorithms out there because the clients wouldn't be able to connect :/
As an added note, your server seems to resolve some A record, despite no A records in the domain.
I suspect whatever you're using for DNS does park all NXDOMAIN into some website of their own.
Is there a good reason to open up access to your ssh port for some service by a novelty account which could easily collect information on what version ssl sub-protocols you do and do not support?
Consider me paranoid but I don't like services like this unless they come from reputable sources and even then I'd much rather run something local.
Remember to close your port in your firewall after running the test.
I'm not sure I get you, I find this service most useful for public-facing SSH services (where the risk of attack in the greatest). I wouldn't bother forwarding my laptop's port 22 just to test it, that's for sure.
If an attacker wants to gather a list of vulnerable SSH servers in the wild they just have to map a bunch of random addresses (and that seems to be extremely common judging by the number of failed auths on my public server). Although it could be useful if you wanted to get a list of ssh servers not running on port 22.
But if it is private you're going to have to unlock a port, let the service do its thing and then re-lock afterwards. If you forget the last step you are now more at risk than before.
Also, since the service does not advertise what IP it will be connecting from beforehand (presumably the host you complete that form on, but that's not a certainty, it's IP is 40.112.150.31, in an MS Azure block) you would open up access to the world in order to do this.
Even if the IP address was guaranteed static then I wouldn't dare recommending admins to add an exception to firewall. That would certainly be a very bad practice. There are tools available (mentioned in the comments around) that do the same job and can be run in the DMZ (the question is, would anyone go through the source code and verify the tool does not contain any malicious code?).
I think it's more the other way round. You already have a public SSH server for whatever reason (e.g. hosting, tunelling, ...) and you might use this tool to check its capabilities.
The reputability of such service or even existence thereof does not have anything to do with how much your server is or is not secured.
and returns almost the same details , there is also a nmap script https://nmap.org/nsedoc/scripts/ssh2-enum-algos.html
I've always found these kind of webapps attractive in a way ... the fact that it may be doing a os.popen("nmap -vv bla bla bla") makes me uncomfortable ,
Call me critical AND paranoid.. but this kind of thing should be a tool people can run locally. Not via some public service, which is probably gonna be blacklisted on plenty of RBLs.
However first and above all, SSH SHOULD NEVER LISTEN AND/OR RESPOND to non whitelisted ip addresses. NEVER, no exceptions.
Also i think it is more a promotion for the rebex site and software, not so much the ssh scan utility... based on the selected sample site, simplicity of the utility and site,
I think it suffice to disable root login, password authentication and maybe use a non-standard port to clear the logs from scanners. What do you do if your address changes or something? I wouldn't risk locking myself out.
Meh, I've got two hosts running SSH that are accessible from anywhere. They run OpenSSH on OpenBSD and are pretty locked down (only specific ciphers, key exchange algorithms, and MACs are permitted), root login is disabled, and password authentication is disabled, among other non-default configuration options. These two hosts allow access (via SSH) to another 40 or so boxes running various flavors and versions of Linux that can't be locked down as much.
I do not worry one bit about those two hosts getting compromised as I took the time to minimize the chances of that happening.
The fact you think that secures you, worries me, and that you share the almost exact setup you have with the world, just as much. Security is layers, and one layer is not telling the world about your setup.
having your server ssh exposed to the world and trusting your configuration is relying on obscurity. Having strict firewalls, with only a limited amount of trusted ip addresses is anything but relying on obscurity.
There are many cases when you don't know the IP you will be connecting from. The only way around that I know of would be a VPN, but SSH's auth and crypto strength is at least as good.
[0] https://wiki.mozilla.org/Security/Guidelines/OpenSSH