6 ms·

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 se

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.

blfr 5y ago
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.
- kroeckx 5y ago
  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.
remram 5y ago
Yeah, I do that. On my box services point to /etc/letsencrypt/live/...
handrous 5y ago
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.Authentication-Modules 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.
- yjftsjthsd-h 5y ago
  I've done approximately that and just used https://github.com/atmoz/sftp 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).
  - handrous 5y ago
    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)
    - yjftsjthsd-h 5y ago
      Oh sure; certainly not dissing your solution, just pointing out that SFTP is also workable now.
- cookiengineer 5y ago
  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.
samizdis 5y ago
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-with-https-connections-by-sending-data-to-your-email-server/ https://arstechnica.com/gadgets/2021/06/hackers-can-mess-wit...
chasil 5y ago
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-released-and-horrors-of-ftp.html https://scarybeastsecurity.blogspot.com/2015/07/vsftpd-303-r...
- hobs 5y ago
  Ah, but IIS uses it so it probably is still floating around somewhere.
- Lex-2008 5y ago
  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 http://www.postfix.org/TLS_README.html
tgsovlerkhgsel 5y ago
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.
technion 5y ago
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.

blfr 5y ago

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.

kroeckx 5y ago
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.

remram 5y ago

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

handrous 5y ago

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.Authentication-Modules 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.

yjftsjthsd-h 5y ago
I've done approximately that and just used https://github.com/atmoz/sftp 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).
- handrous 5y ago
  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)
  - yjftsjthsd-h 5y ago
    Oh sure; certainly not dissing your solution, just pointing out that SFTP is also workable now.
cookiengineer 5y ago
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.

samizdis 5y ago

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-with-https-connections-by-sending-data-to-your-email-server/ https://arstechnica.com/gadgets/2021/06/hackers-can-mess-wit...

chasil 5y ago

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-released-and-horrors-of-ftp.html https://scarybeastsecurity.blogspot.com/2015/07/vsftpd-303-r...

hobs 5y ago
Ah, but IIS uses it so it probably is still floating around somewhere.
Lex-2008 5y ago
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 http://www.postfix.org/TLS_README.html

tgsovlerkhgsel 5y ago

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.

technion 5y ago

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.