Another Secure FTP thread -- Protection Levels - Protocols

This is a discussion on Another Secure FTP thread -- Protection Levels - Protocols ; Read through the other FTP thread -- very helpful. The obstacle I'm dealing with is connecting to a secure FTP server through our router. I'm behind a Linksys router which for some reason doesn't like to read encrypted packets. Here's ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Another Secure FTP thread -- Protection Levels

  1. Another Secure FTP thread -- Protection Levels

    Read through the other FTP thread -- very helpful.

    The obstacle I'm dealing with is connecting to a secure FTP server
    through our router. I'm behind a Linksys router which for some reason
    doesn't like to read encrypted packets.

    Here's what I tried with a newly-compiled CKERMIT 8.12:

    set ftp autoencryption off
    set ftp authtype ssl
    set ftp command-protection-level clear
    ftp ###.###.###.### /user:##### /password:#####

    It responds with:
    Connected to ###.###.###.###
    SSL accepted as authentication type

    ....then the self-signed certificate issue discussed in the other
    thread, but not a crisis at this time.

    The issue is a SHOW FTP returning:

    Available security methods:

    ftp authtype: SSL
    ftp auto-encryption: off
    ftp credential-forwarding: off
    ftp command-protection-level: safe
    ftp data-protection-level: private
    ftp secure proxy: (not set)

    How come when I set the command-protection-level to clear, it connects
    as safe? Is this dictated by the server?


  2. Re: Another Secure FTP thread -- Protection Levels

    C-Kermit does not allow the command channel to be reset to clear
    after it is protected by AUTH TLS. This is simply not permitted.

    Jeffrey Altman


    Ed Gage wrote:
    > Read through the other FTP thread -- very helpful.
    >
    > The obstacle I'm dealing with is connecting to a secure FTP server
    > through our router. I'm behind a Linksys router which for some reason
    > doesn't like to read encrypted packets.
    >
    > Here's what I tried with a newly-compiled CKERMIT 8.12:
    >
    > set ftp autoencryption off
    > set ftp authtype ssl
    > set ftp command-protection-level clear
    > ftp ###.###.###.### /user:##### /password:#####
    >
    > It responds with:
    > Connected to ###.###.###.###
    > SSL accepted as authentication type
    >
    > ....then the self-signed certificate issue discussed in the other
    > thread, but not a crisis at this time.
    >
    > The issue is a SHOW FTP returning:
    >
    > Available security methods:
    >
    > ftp authtype: SSL
    > ftp auto-encryption: off
    > ftp credential-forwarding: off
    > ftp command-protection-level: safe
    > ftp data-protection-level: private
    > ftp secure proxy: (not set)
    >
    > How come when I set the command-protection-level to clear, it connects
    > as safe? Is this dictated by the server?
    >


  3. Re: Another Secure FTP thread -- Protection Levels

    I don't think I was using TLS. I even turned the autoencryption off
    and forced the AUTHTYPE to be SSL. The SHOW FTP indicates that it
    indeed is using SSL, not TLS. Or am I missing something all together?


  4. Re: Another Secure FTP thread -- Protection Levels

    Ed Gage wrote:
    > I don't think I was using TLS. I even turned the autoencryption off
    > and forced the AUTHTYPE to be SSL. The SHOW FTP indicates that it
    > indeed is using SSL, not TLS. Or am I missing something all together?
    >


    SSL 1.0, SSL 2.0, SSL 3.0 == TLS 1.0, SSL 3.1 == TLS 1.1

    SSL was a proprietary protocol from Netscape. When it was standardized
    by the IETF the name was changed.




  5. Re: Another Secure FTP thread -- Protection Levels

    So is there a way, then, to "dummy down" the SSL? I used openSSL 0.9.7
    for the compile.


  6. Re: Another Secure FTP thread -- Protection Levels

    Ed Gage wrote:
    > So is there a way, then, to "dummy down" the SSL? I used openSSL 0.9.7
    > for the compile.


    This has nothing to do with dummying down the SSL. C-Kermit does not
    implement the functionality. Can the functionality be added to C-Kermit
    by a programmer familiar with both the FTP authentication protocols
    and C-Kermit? Yes.


  7. Re: Another Secure FTP thread -- Protection Levels

    Your response suggests that there might be other products out there
    that would have this capability. If so, what are they? Alternatively,
    if we select a router that has a firewall which allows external
    addresses to map to an internal NAT-protected IP, would that also solve
    the problem?


  8. Re: Another Secure FTP thread -- Protection Levels

    Ed Gage wrote:
    > Your response suggests that there might be other products out there
    > that would have this capability. If so, what are they? Alternatively,
    > if we select a router that has a firewall which allows external
    > addresses to map to an internal NAT-protected IP, would that also solve
    > the problem?


    Ed:

    Didn't this thread start because you had another product that did have
    this functionality and you wanted to know if you could replace it with
    C-Kermit?

    Here is your problem. Your company wants to have secure communications
    between a client that you control and a remote server that you do not
    control. In order to do this, you must create a mutually authenticated,
    encrypted, and integrity protected channel between your client and the
    remote server. At no point during the communication session can you
    allow the encryption or integrity protection to drop without becoming
    susceptible to an active attack whereby the attacker waits until the
    authentication has been performed and then steals the tcp session.

    At the same time your company doesn't want to allow an communication
    through your firewall that is not authorized. You are enforcing that
    policy by requiring the firewall to snoop each session and if it is
    FTP either restrict what commands can be sent or logging each command
    that is sent so that there would be evidence of the transfer of a trade
    secret. This is incompatible with the concept of a secure private
    session between your client and the remote server.

    You can't have it both ways. I don't write insecure applications.
    If you want to hire someone to make your communications insecure you
    can by all means do so. But if you are going to use software I wrote
    to perform a secure communication then that communication is going to
    be secure.

    The whole notion of firewalls acting as the man in the middle is flawed.
    You can't be the man in the middle when using http over ssl/tls to
    communicate with your bank. Why should you be able to do so when the
    protocol is ftp?

    Jeffrey Altman

  9. Re: Another Secure FTP thread -- Protection Levels

    In article , jaltman2
    @nyc.rr.com says...
    > Ed Gage wrote:
    > > Your response suggests that there might be other products out there
    > > that would have this capability. If so, what are they? Alternatively,
    > > if we select a router that has a firewall which allows external
    > > addresses to map to an internal NAT-protected IP, would that also solve
    > > the problem?

    >
    > Ed:
    >
    > Didn't this thread start because you had another product that did have
    > this functionality and you wanted to know if you could replace it with
    > C-Kermit?
    >
    > Here is your problem. Your company wants to have secure communications
    > between a client that you control and a remote server that you do not
    > control. In order to do this, you must create a mutually authenticated,
    > encrypted, and integrity protected channel between your client and the
    > remote server. At no point during the communication session can you
    > allow the encryption or integrity protection to drop without becoming
    > susceptible to an active attack whereby the attacker waits until the
    > authentication has been performed and then steals the tcp session.
    >
    > At the same time your company doesn't want to allow an communication
    > through your firewall that is not authorized. You are enforcing that
    > policy by requiring the firewall to snoop each session and if it is
    > FTP either restrict what commands can be sent or logging each command
    > that is sent so that there would be evidence of the transfer of a trade
    > secret. This is incompatible with the concept of a secure private
    > session between your client and the remote server.
    >
    > You can't have it both ways. I don't write insecure applications.
    > If you want to hire someone to make your communications insecure you
    > can by all means do so. But if you are going to use software I wrote
    > to perform a secure communication then that communication is going to
    > be secure.
    >
    > The whole notion of firewalls acting as the man in the middle is flawed.
    > You can't be the man in the middle when using http over ssl/tls to
    > communicate with your bank. Why should you be able to do so when the
    > protocol is ftp?
    >
    > Jeffrey Altman


    I think to do this, the OP's company's security people need to set up a
    gateway or proxy system (not the firewall) to act as an FTP relay
    between his system and the remote system. There would then be two FTP
    connections, his system to the gateway, and gateway (through the
    firewall) to the remote system. He would need to establish his FTP
    session to the gateway, telling it via some magic (encoded in the
    username or file specification or stored in a config file on the gateway
    or ...) that he really wanted to send the file to the remote system (or
    that he wanted to pull it back). The gateway would then set up a
    second (encrypted) FTP session to the remote end. It would receive
    packets from the first system, decrypt them, do what ever validation
    and logging is needed, re-encrypt them and send them over the 2nd FTP
    connection to the remote end. The same in reverse for the reply
    packets. The encryption between your system and the gateway and the
    encryption between the gateway and the remote system need not have any
    connection: separate keys, certificates, algorithms, etc. (He may not
    even need any encryption between his system and the gateway; that
    depends on how much the security people trust their corporate network.
    Most likely it will be required, though.)

    The firewall would be coded to allow encrypted traffic from the gateway
    server (but not his own system) to the specified remote system, and
    rely on the gateway to do the necessary validation and logging. Both
    the gateway and the firewall would be under control of the security
    people, not the end users.

    You (the OP) could use Kermit to do the FTP client functions on your
    system, just as you do (or are trying to do) now. For that matter, you
    could probably implement the gateway system as a giant Kermit macro, too
    :-)

    I think secure FTP gateways (not sure what they are called) are
    available commercially. At least one company I know of uses one to
    send credit card information to the company that actually manufactures
    and mails the credit cards to their customers, so it must be fairly
    secure. I don't know if the gateway they are using is home-brew or
    COTS. Maybe the firewall people at the OP's company already have
    one - he should ask.


    --
    John

  10. Re: Another Secure FTP thread -- Protection Levels

    John Santos wrote:

    > I think to do this, the OP's company's security people need to set up a
    > gateway or proxy system (not the firewall) to act as an FTP relay
    > between his system and the remote system. There would then be two FTP
    > connections, his system to the gateway, and gateway (through the
    > firewall) to the remote system. He would need to establish his FTP
    > session to the gateway, telling it via some magic (encoded in the
    > username or file specification or stored in a config file on the gateway
    > or ...) that he really wanted to send the file to the remote system (or
    > that he wanted to pull it back). The gateway would then set up a
    > second (encrypted) FTP session to the remote end. It would receive
    > packets from the first system, decrypt them, do what ever validation
    > and logging is needed, re-encrypt them and send them over the 2nd FTP
    > connection to the remote end. The same in reverse for the reply
    > packets. The encryption between your system and the gateway and the
    > encryption between the gateway and the remote system need not have any
    > connection: separate keys, certificates, algorithms, etc. (He may not
    > even need any encryption between his system and the gateway; that
    > depends on how much the security people trust their corporate network.
    > Most likely it will be required, though.)


    This would require that the private keys that are supposed to be
    controlled by the user must be in the possession of the firewall.

    As far as I am concerned firewalls, should not be involved in
    decrypting my traffic. You want firewalls to authenticate outgoing
    connections in order to ensure that only those services running
    on approved machines are allowed to make connections to the
    destination address.

    We had a solution for this years ago, its called SOCKS v5. The
    client machine opens a socket level connection to the firewall
    which instructs the client whether the desired connection
    should be established:

    * direct to the destination

    * through the firewall without authentication

    * through the firewall with authentication

    * or is not permitted.

    The application running on the client is unaware of this negotiation.
    When the application connects to the destination it may or may not be
    using a redirected socket. It is completely unaware.

    > The firewall would be coded to allow encrypted traffic from the gateway
    > server (but not his own system) to the specified remote system, and
    > rely on the gateway to do the necessary validation and logging. Both
    > the gateway and the firewall would be under control of the security
    > people, not the end users.
    >
    > You (the OP) could use Kermit to do the FTP client functions on your
    > system, just as you do (or are trying to do) now. For that matter, you
    > could probably implement the gateway system as a giant Kermit macro, too
    > :-)
    >
    > I think secure FTP gateways (not sure what they are called) are
    > available commercially. At least one company I know of uses one to
    > send credit card information to the company that actually manufactures
    > and mails the credit cards to their customers, so it must be fairly
    > secure. I don't know if the gateway they are using is home-brew or
    > COTS. Maybe the firewall people at the OP's company already have
    > one - he should ask.


    The problem with this is that I don't trust the security people and
    neither should you. In fact, the security people shouldn't trust the
    security people because you never know when someone is going to become
    compromised.

    Clients are issued certificates, tickets, or other credentials to
    authenticate the client. They are not meant to be used to authenticate
    the firewall. If you give all of your credentials to the firewall then
    not only do the administrators of the firewall have the ability to
    impersonate you but so does anyone that is able to compromise the
    firewall. There have been plenty of security holes in the operating
    systems that firewalls and routers run on that would allow for the box
    to be compromised by an attacker. By intentionally installing a man
    in the middle, you are opening the door to significant risk.

    Jeffrey Altman

  11. Re: Another Secure FTP thread -- Protection Levels

    Jeffrey Altman wrote:
    > As far as I am concerned firewalls, should not be involved in
    > decrypting my traffic. You want firewalls to authenticate outgoing
    > connections in order to ensure that only those services running
    > on approved machines are allowed to make connections to the
    > destination address.


    Pernicious corporate entities might want to moderate all of the traffic.
    I was trapped in an environment where no encryption was allowed through the
    firewall. The intent was to block any virus from entering, but, when
    stupidity abounds, what they did was bring our customer interaction to a
    screeching halt.

    > We had a solution for this years ago, its called SOCKS v5. The
    > client machine opens a socket level connection to the firewall


    We lived with that abomination for a while, until it cracked under the
    strain and complaints from the users. (Every user that complained was told
    they were the only one with complaints.)

    > The application running on the client is unaware of this negotiation.


    Sigh. It didn't really work very well, and thankfully, I've forgotten...
    no, I haven't... "eBorder".

    > When the application connects to the destination it may or may not be
    > using a redirected socket. It is completely unaware.


    Some of that routing was under control of the same incompetent admins that
    were responsible for mangling the SOCKS firewall.

    > The problem with this is that I don't trust the security people and
    > neither should you. In fact, the security people shouldn't trust the
    > security people because you never know when someone is going to become
    > compromised.


    They are sniffing everything. That's why they don't like encryption, but,
    as Jeff notes, it means you have to trust them.

    In amongst the technical absurdities in Dan Brown's "Digital Fortress" is
    the underlying theme that everybody at NSA was sniffing everybody else's
    private traffic, and doing stupid things with their knowledge.

    --
    ---
    Clarence A Dold - Hidden Valley Lake, CA, USA GPS: 38.8,-122.5

  12. Re: Another Secure FTP thread -- Protection Levels

    In article , jaltman2
    @nyc.rr.com says...
    > John Santos wrote:
    >
    > > I think to do this, the OP's company's security people need to set up a
    > > gateway or proxy system (not the firewall) to act as an FTP relay

    ^^^^^^^^^^^^^^^^

    > > between his system and the remote system. There would then be two FTP
    > > connections, his system to the gateway, and gateway (through the
    > > firewall) to the remote system. He would need to establish his FTP
    > > session to the gateway, telling it via some magic (encoded in the
    > > username or file specification or stored in a config file on the gateway
    > > or ...) that he really wanted to send the file to the remote system (or
    > > that he wanted to pull it back). The gateway would then set up a
    > > second (encrypted) FTP session to the remote end. It would receive
    > > packets from the first system, decrypt them, do what ever validation
    > > and logging is needed, re-encrypt them and send them over the 2nd FTP
    > > connection to the remote end. The same in reverse for the reply
    > > packets. The encryption between your system and the gateway and the
    > > encryption between the gateway and the remote system need not have any
    > > connection: separate keys, certificates, algorithms, etc. (He may not
    > > even need any encryption between his system and the gateway; that
    > > depends on how much the security people trust their corporate network.
    > > Most likely it will be required, though.)

    >
    > This would require that the private keys that are supposed to be
    > controlled by the user must be in the possession of the firewall.
    >


    No, the gateway system is not the firewall. It would probably be run
    by the network security people, but could be a different set of people
    than do the firewalls. (The firewall people would have to trust the
    gateway people to properly monitor and record the sessions, and permit
    connections from the gateway to the remote system while blocking FTP
    connections to or from anywhere else.)

    > As far as I am concerned firewalls, should not be involved in
    > decrypting my traffic. You want firewalls to authenticate outgoing
    > connections in order to ensure that only those services running
    > on approved machines are allowed to make connections to the
    > destination address.


    In my scenario, the firewall does *NOT* decrypt the traffic.

    > We had a solution for this years ago, its called SOCKS v5. The
    > client machine opens a socket level connection to the firewall
    > which instructs the client whether the desired connection
    > should be established:
    >
    > * direct to the destination
    >
    > * through the firewall without authentication
    >
    > * through the firewall with authentication
    >
    > * or is not permitted.
    >
    > The application running on the client is unaware of this negotiation.
    > When the application connects to the destination it may or may not be
    > using a redirected socket. It is completely unaware.
    >
    > > The firewall would be coded to allow encrypted traffic from the gateway
    > > server (but not his own system) to the specified remote system, and
    > > rely on the gateway to do the necessary validation and logging. Both
    > > the gateway and the firewall would be under control of the security
    > > people, not the end users.
    > >
    > > You (the OP) could use Kermit to do the FTP client functions on your
    > > system, just as you do (or are trying to do) now. For that matter, you
    > > could probably implement the gateway system as a giant Kermit macro, too
    > > :-)
    > >
    > > I think secure FTP gateways (not sure what they are called) are
    > > available commercially. At least one company I know of uses one to
    > > send credit card information to the company that actually manufactures
    > > and mails the credit cards to their customers, so it must be fairly
    > > secure. I don't know if the gateway they are using is home-brew or
    > > COTS. Maybe the firewall people at the OP's company already have
    > > one - he should ask.

    >
    > The problem with this is that I don't trust the security people and
    > neither should you. In fact, the security people shouldn't trust the
    > security people because you never know when someone is going to become
    > compromised.
    >


    If you don't trust the security people, fire them, immediately :-)

    > Clients are issued certificates, tickets, or other credentials to
    > authenticate the client. They are not meant to be used to authenticate
    > the firewall. If you give all of your credentials to the firewall then
    > not only do the administrators of the firewall have the ability to
    > impersonate you but so does anyone that is able to compromise the
    > firewall. There have been plenty of security holes in the operating
    > systems that firewalls and routers run on that would allow for the box
    > to be compromised by an attacker. By intentionally installing a man
    > in the middle, you are opening the door to significant risk.


    1) The gateway is neither a router nor a firewall.

    2) You can encrypt the data separately, end-to-end. The gateway can't
    tell if it is legitimate or not anyway. (I'm sure there is an
    information theory proof of this - if the gateway could validate the
    data, it could probably produce it in the first place, obviating the
    need for the client system to exist.)

    What the gateway is trying to validate is the direction of data flow,
    the file names being sent or received, and possibly the timing and
    amount of data and any other information it can pick out of the FTP
    protocol. In addition, the firewall still validates the source and
    destination systems, even it can't filter on the content.


    3) Rhetorical question: Who is the client? Is it some system on
    corporate network, or is it the corporation itself? The end system
    users, the firewall administrators, etc. are all employees or agents
    of the corporation, so in that sense, they are all the client.

    >
    > Jeffrey Altman
    >


    --
    John

+ Reply to Thread