Cyberduck Mountain Duck CLI

Changes between Initial Version and Version 1 of Ticket #5087, comment 7


Ignore:
Timestamp:
Sep 17, 2010 12:08:52 PM (9 years ago)
Author:
abrax5
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #5087, comment 7

    initial v1  
    1 Pretty difficult indeed, it seems. I looked at the GNU classpath code to get an idea. In {{{\gnu\javax\net\ssl\provider\AbstractHandshake.java}}} there is a function called {{{generateMasterSecret()}}} which seems to be responsible for generating the session key according to TLS/SSL spec. This one is of course well hidden behind the whole public SSL/TLS Java API and it would be quite hard to mess with this and inject a predefined session key, IMHO.
     1I looked at GNU classpath, and there's a file called ClientHandshake.java:
    22
    3 Does ProFTPd skip the handshake altogether on the second connection? Or how do they intend to make that connection reuse the session key? Is this still a valid/spec-compliant TLS session in this case or do they deviate from the protocol? Are there actually FTP client implementations who manage to do that?
     3{{{
    44
     5            case WRITE_CLIENT_HELLO:
     6            {
     7              ClientHelloBuilder hello = new ClientHelloBuilder();
     8              AbstractSessionContext ctx = (AbstractSessionContext)
     9                engine.contextImpl.engineGetClientSessionContext();
     10              continued = (SessionImpl) ctx.getSession(engine.getPeerHost(),
     11                                                       engine.getPeerPort());
     12}}}
     13
     14Maybe Cyberduck could use a modified version of GNU classpath for this use case and modify the AbstractSessionContext implementation so that it returns a previously used session for the same host even though the port is different?
swiss made software