Name-based virtual hosts not working as expected after upgrade from 1.3.7a to 1.3.7b #1369
Comments
|
binding trace: Shouldn't there only be 1 |
|
Indeed there should; this particular area is still in a bit of flux. It's possible that this issue of yours was addressed by 2526301 -- I'll try to reproduce it locally. |
|
I just tried using the latest latest git (915624a) version, but there are still 2 ipbinds and the issue persists. |
|
I was not able to reproduce this behavior using the latest ProFTPD from master, which indicated that it was fixed at some point the past; I was able to reproduce this bug using 1.3.7c, so the fix was fairly recently. Some digging turned up this commit; I verified that it does indeed address the issue. I'll be backporting this commit to the 1.3.7 branch. |
…nch, so that namebased <VirtualHost> blocks work with TLS SNI properly once more.
|
Hmm, this concrete problem with two exact ServerName entries seems to be solved. Although I still see 2 ipbinds on latest master. However, there is another problem with a wildcard ServerName. E.g. Click to expandI'd expect this to behave as a catch-all fallback. That means:
However, this is not the case. b) If i swap the order of the two blocks in the config file, a request with no SNI at all returns the one for servername In 1.3.7a these scenarios worked as expected. |
|
Good feedback, much appreciated. In my opinion, a This is the behavior that I would expect, and the behavior that I'll implement. |
|
Ah, right -- this is why a configuration of But you're right, a configuration of
|
Hmm, good question, most specific would need to be clearly defined. E.g. what if there are two blocks
I guess fist match wins (in the order defined in the config file) would be clear and it would allow exactly that catch-all scenario.
So a catch-all would be easy to implement and it would probably be compatible with what 1.3.7a has been doing (even if it was not intentional there). And I'd expect that a request without SNI (e.g. using only the IP) would then also be handled by the last one. |
…e ProFTPD internals, to maintain proper insertion order.
…oFTPD internals from the main branch to 1.3.7.
…oFTPD internals from the main branch to 1.3.7.
This expectation is a bit harder, since that particular functionality is supposed to be handled by the |
|
Things work well if there are only vhosts with explicitly defined However, I still am not able to make create a catch-all fallback that catches connections without SNI (just with the IP address). If I define a 3rd vhost like this: If I connect with an arbitrary SNI: I end up on the 3rd vhost as intended. But If I connect without SNI: I still end up on the 1st one. This is not desired. Also: |
|
Currently, the implementation is this:
If your configuration doesn't have |
I don't know, I guess that would be undefined. The point is: If I do have them configured I definitely don't what a request without SNI to end up on any of the other ones. |
|
While it might be ugly, based on the first-match-wins implementation, here's what you would currently need to use: An alternative might to use something like |
|
While we continue discussing how best to deal with the question of which |
|
No objections. Those definitely make sense and improve the SNI behavior. The behavior for initial/non-SNI connections is a different issue. |
This doesn't work. With that config, using a connection with SNI I end up on the first block (the one without |
…e ProFTPD internals, to maintain proper insertion order.
…oFTPD internals from the main branch to 1.3.7.
Issue #1369: Tuning the handling of IP- and name-based bindings in th…
Issue #1369: Backporting much of the IP- and name-based tunings of Pr…
|
Dear TJ, In the other hand, re-emerging v1.3.7.a (it's Gentoo), after login I'm now touching #1111, i.e. users may need to choose another MAC, which isn't acceptable. How to get something working in-between at least, please? May I cherry-pick #1181 ? |
|
OK, after carefully reading #1111 and #1181 I understand and may confirm that applying the patch solves the issue with the MAC caused by gcc ( But we have to solve the wrong vhost issue for >=v1.3.8 here; do you need any information from me to work on? |
|
@gjaekel Can you provide the ProFTPD config you're using, so that I can better understand the issue you are seeing? I'm not sure I understand what you mean by:
Also, SSH/SFTP connections are purely based on IP address/port; there is no name-based selection involved, as SSH does not have the protocol equivalent of TLS SNI or HTTP |
TLTR: Yes - It can't work by definition. By sharing one IP for more than one vhost, we did a fundamental mistake I remember and realize this over last hours, too. And therefore, I double-checked the issue facts reported to me. The solution is lame: For any reason, the different versions of proftpd evaluate the clashing vhost definitions in different order. Therefore, either the one or the other vhost is usable. The "missleading point" was that there is the same account with identical credentials used for both vhost. And in former times, we seems just to verify that to procedure of login, but not the data that is available afterwards. It never had have worked in the suggested way, I conclude. And for historical reasons, in the production setup we use different IPs. Therefore this mistake never get eye-catching. BTW: Using ProFTPd, we only offer ssh-ftp/cp (and also WebDAV via an Apache httpd on the same domains sharing the same accounts file). Sorry for the rumor. |
|
@gjaekel No worries, and thanks for the update. When it comes to address/port "collisions" (overuse) in the ProFTPD config file, over the years I've wavered between having ProFTPD refuse to start up all for such misconfigurations, or logging about the collision (and thus having these logs easily missed by administrators) and proceeding on. Currently, it's the latter behavior, which I felt to be less surprising, more admin-friendly -- but at the cost of missing such misconfigurations. Hopefully, with the work being done in this ticket, the order in which vhosts are evaluated by ProFTPD will be more stable/consistent. |
|
@m0vie when you say
How are you verifying that you end up on the first vhost, the one that lacks the |
…as` directive, but does not have an explicit `ServerName`, then use the first `ServerAlias` as the `ServerName`.
Issue #1369: If we encounter a <VirtualHost> that uses the `ServerAli…
|
@Castaglia Very prudent! In sum I tracked down an already existing conceptual mistake by our own and while investigating this, I stepped into this special gcc issue (#1111, #1181). And shot myself in the foot by having the same credentials for a test account on different vhosts. Nothing of this was caused by ProFTP itself in the root. You may take this as a proof that it might be better to refuse startup on misconfigurations for some future release. There are more and more unattended updates happen by orchestration or similar, where nobody will read logs to discover "silent errors". |
|
I think 8a186da fixed things for me: This is exactly what I'd expect and things looks deterministic now. |
Castaglia
changed the title
|
I tested with 8a186da backported on top of 1.3.7c and things seem to be good for me (re: issue #1105 that came back in the 1.3.7 branch). To be clear, I have not tested 1.3.7c without 8a186da (because at this point, why), nor have I tested master/8a186da directly (because that's non-trivial for me to do in production). |
|
Considering this ticket addressed; we'll use new tickets for any other issues that come up. Thanks, all! |
What I Did
Upgraded from 1.3.7a to 1.3.7b.
What I Expected/Wanted
A simple config (containing 2 VirtualHosts for the same IP / port) that worked fine on 1.3.7a does not anymore on 1.3.7b. Example config see below.
Before 8c3ad20:
After 8c3ad20:
proftpd.log:
A git-bisect shows that this is a side-effect of 8c3ad20 (#1105 / #1109).
ProFTPD Version and Configuration
The text was updated successfully, but these errors were encountered: