Hacker News Reader

Comment by jsiepkes | Hacker News Reader

It's an interesting read but as they acknowledge themselves the attack surface is probably pretty low.

> Sharing certificates between a Webserver and an FTP server is almost always dangerous if an attacker has write access to the FTP server. It is sometimes dangerous if the attacker has no write access.

When dealing with "secure FTP" it is usually SFTP (so actually SSH so no TLS / certificate in the picture) instead of FTPS (ie. actual FTP + TLS). I don't think I've ever seen FTPS in the wild. But thats just my personal experience.

> Sharing certificates between a Webserver and an SMTP/POP3/IMAP server is sometimes dangerous, depending on the exact behavior of the server.

Are there people who do that? I don't think I've ever seen a SMTP or IMAP server with a wildcard certificate. Let alone the cert being shared with a HTTP server.

View on HN

I implemented an FTPS service once! AMA?

My needs were: 1) Client login [edit: should have been more clear—I mean randos who signed up on our website, basically], 2) username and password login, no key stuff, 3) obviously plain FTP was not an option.

Nice to have: 1) Same username and password as the website, not managed separately.

My personal hang-up: 1) I really didn't want to create actual system users for any of this.

I settled on ftps, which could satisfy all the needs plus my hang-up, and then chose PureFTPd which made implementing the nice-to-have very easy:

https://download.pureftpd.org/pub/pure-ftpd/doc/README.Authe...

I'd already factored out our auth into what you'd call a microservice (I think the term was just starting to enter wide use then?) because we needed to serve multiple barely-related services with the same auth, so writing a little script to handle that auth was downright trivial. The only reason it took more than an hour, once I settled on a solution, was that I had to make it play nice with haproxy, and I wanted to thoroughly test my auth script's failure modes.

This basically never broke. It was great.

A++++ would ftps again.

I remember that BSDs original ftpd had a login password limitation with a wrong bytes allocation and a resulting RCE attack surface, which ultimately is still a threat to outdated ProFTPd instances running on Windows. (see exploitdb, it's full of PoCs)

I always asked myself: Why not simply use sshd and no login shell for the created user? Gives you legit transport encryption, blocking of keys/certs you wanna ban, and is the definition of battleproven software.

I never understood plaintext auth via encrypted transportation layers. They simply don't make sense to me from a security standpoint, and the risks of a broken transport layer is just too damn high as you must have control of every OSI level to really be able to verify it and that's never the case.

I've done approximately that and just used https://github.com/atmoz/sftp bound to port 2222 or whatever. SFTP supports password auth just fine if you like, and AFAIK is at least as accessible and probably moreso (clients like filezilla will support both, and sftp shhould be preinstalled on most unix-likes).

Right, of course you can use password auth with sftp, but 1) there was no docker at the time (as in the linked repo), 2) lxc itself was very new at the time, in fact, and 3) that project appears to create system users (in the container) which was one thing I was trying to avoid doing, without adding undue complexity (LDAP or whatever). My solution was mature at the time, relied entirely on our existing auth system so there was no need to keep accounts in sync or manage them separately, and didn't cause any complications with permissions for which directories an account could access (if our normal auth system said a user could access ftps for a given project, then they could, and that was it—no messing with Unix permissions and groups or, more likely, Linux ACL-based permissions, and keeping those in sync with the settings on the site)

Oh sure; certainly not dissing your solution, just pointing out that SFTP is also workable now.

From an Ars Technica report about this [1], citing the researchers:

"Overall, the attack is very situational and targets individual users," Brinkmann said. "So, the individual risk for users is probably not very high. But over time, more and more services and protocols are protected with TLS, and more opportunities for new attacks that follow the same pattern arise. We think it's timely and important to mitigate these issues at the standardization level before it becomes a larger problem."

[1] https://arstechnica.com/gadgets/2021/06/hackers-can-mess-wit...

I'm actually sharing a cert between a web server and another service. Refreshing the certificate with certbot is trivial if the cert is being used on a web server, and reusing the same cert for another service is easier than figuring out a separate way to refresh that cert.

I have no clue if the second service is vulnerable to this attack though - I kind of doubt it.

This is why you have never seen FTPS in the wild, from the vsftpd.conf manual page:

    ssl_enable
    If enabled, and vsftpd was compiled against OpenSSL, vsftpd will
    support  secure connections via SSL. This applies to the control
    connection (including login) and also data  connections.  You'll
    need a client with SSL support too. NOTE!!  Beware enabling this
    option. Only enable it if you need it. vsftpd can make no  guar‐
    antees  about the security of the OpenSSL libraries. By enabling
    this option, you are declaring that you trust  the  security  of
    your installed OpenSSL library.
    Default: NO

https://scarybeastsecurity.blogspot.com/2015/07/vsftpd-303-r...

Postfix has a similar note:

> NOTE: By turning on TLS support in Postfix, you not only get the ability to encrypt mail and to authenticate remote SMTP clients or servers. You also turn on hundreds of thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000 lines introduce one additional bug into Postfix.

http://www.postfix.org/TLS_README.html

Ah, but IIS uses it so it probably is still floating around somewhere.

I use the same certificate for http and smtp on my small personal server since they have the same hostname and it's easier to generate with Let's Encrypt through http.

I suggest you have a hostname for each service. So you could change the hostname of the mx but have it point to the same IP address. You can then have a certificate for each hostname. Certbot can generate/renew the certificate using http even if that hostname normally doesn't do http.

Yeah, I do that. On my box services point to /etc/letsencrypt/live/...

Microsoft exchange runs SMTP and web. It needs a minimum of two names to function, and can require several others depending on features. Microsoft just released a vulnerability fix that actually requires you add a new unique name to your certificate. That sort of annoyance often leads people to use wildcards. And prior to let's encrypt, a wildcard is often cheaper than a cert with six names like I've been dealing with. So in that situation, there are a lot of SMTP wildcards on a web server in the wild.

Reply on news.ycombinator.com