Does attacker need to be in possession of the ftp.bank.com in the example? If he is not, then what does he gain by the protocol switching? As he is not in possession so whatever is uploaded he cannot read?
I should reat the paper more carefully I guess.
As I understood, by initiating an FTP upload and redirecting the TLS-secured request to the FTP's data port, the entire HTTP request (including cookies in the header) are "uploaded" to the FTP site. This can then be downloaded by the attacker, and now they've exfiltrated the data like the session id (and can do a session hijack attack).
A related attack can be done by placing an HTTP response on the FTP site, and getting the victim's browser to "request" that. This allows the attacker to inject javascript.
These work with certain other protocols, too, but varies by the server and browser tolerance for unrecognized stuff in a request (eg: SMTP will ignore HTTP headers, allowing an SMTP session to be embedded in a POST request as a <textarea>; IE will ignore POP3 "junk" before the beginning of an HTTP response embedded in an email body).
in plaintext http world, man-in-the-middle (MitM) can redirect your browser request for www.bank.com to their own evil server which will pretend being www.bank.com.
in https world this wouldn't work since evil server doesn't have a valid TLS certificate for www.bank.com and thus your browser will refuse to talk to it.
However, MitM might redirect your request for www.bank.com to this bank's ftp server ftp.bank.com. If this mail server uses wildcard certificate *.bank.com - then your browser will accept it and start talking HTTP to it.
this article analyzes how various (email and ftp) software reacts when sees a browser talking http to them. If an ftp server saves such request (in plaintext form) to a world-readable file - hacker can read it and we're in trouble.
Which, OK, is not as strong access as "full access to HTTP traffic". Got it.