Difference between revisions of "Seon Core - OFTP2 getting started"

Revision as of 10:11, 28 February 2013

In order to use the most-actual communication protocol OFTP2, you have to investigate several options.

Certificate

OFTP2 is based on X509v3 certificates with special options contained in them. When using such an OFTP2 certificate, you have to decide from which issuer (from which CA; Certificate Authority) you order your certificate. Many profit-oriented companies exist in the world, also non-profit organisations. The key thing on certificates is:

Is the issuer trusted by my communication partner(s)?

So you have to deal with the question, who your provider of your OFTP2 certificate is.

Every certified (by Odette) OFTP2 system on the market must be able to support a TSL, a list of CAs which are trusted by default. Odette is hoster of the most commonly TSL in the OFTP2 world. In this TSL, a growing number of CAs are included which every major OFTP2 installation should trust. So, if your certificate is issued by a CA included in the Odette TSL, you're on the best way for a seamless usage of your certificate.

Security options

OFTP2 offers a wide range of security options, which are:

• encrypted TCP/IP communication, aka. TLS ("Transport Layer Security"; the successor of SSLv3)
• secure authentification
• file encryption
• file compression
• file signing
• signed EERPs ("End to End ResPonse"; file transfer acknowledgement)

Every single option is optional, but most commonly the TLS layer is the basis for a secure OFTP2 communication. Every option (except of the compression) can(!) be handled with a single different certificate, but most commonly the certificate used for every operation is the same. If you want an extremely complex situation, you can implement a configuration where different certifiates can be used for every single operation for every single partner. (This is an recommendation: use one certificate for all operations. You'll ease up you administrative live.)

In general there is a recommendation: the less security options you choose, the less overhead in administration and CPU and/or I/O power you need. Here's a view of what you need when using these options:

• TLS: configure a TLS server (and optionally: TLS client) certificate on your OFTP2 system
• secure authentification, file encryptioon, file signing, signed EERP: exchange certificate with partner, retrieve certificate of partner, configure your own and partner's certificate to be used for these operations.

The TLS-only usage lowers the administrative overhead, might be the best choice for most installations. If you need more security or traceable logging of files, you might need to consult if you need signing and/or encryption in any situation.

External reachability

Your system should be available world-wide, so you want to be reachable on a single defined port, most commonly for TLS. This default port has the number 6619 and is named as "odette-ftps" in most modern operating systems. You need TCP communication, UDP is not supported by OFTP2. You only need this single port for incoming communication. For outgoing communication, the outgoing port is allocaed randomly, such as in every single socket-based communication software.

You can achieve the external availability in several ways, depending on your own network security policy:

• Install the OFTP2 server directly on a host which is connected to the internet; implement a local firewall on that system.
• Port-forwarding of the incoming port on a centralized internet access to your OFTP2 machine (where the server for TLS listens on a pre-defined port; default 6619).
• Implement a chain of forwardings from zone to zone via any routers, gateways of other network security solutions.
• Use the OFTP2 proxy, install the server in the DMZ, the client in an internal (or intermediate) zone, reachable from your internal network. Up to three network segments, each secured by firewall rules, are supported.