The way FTPS (FTP+TLS) works is that you connect on port 21, issuing the "STARTTLS" command (or some such). You then perform your handshake over an encrypted channel.
FTP requires the use of ports 20 (data) and 21 (control). Though, in practice, 21 is the important port as the one used for data is often negotiated to something above 1024, as well as the new port used by the control channel. >From that point, you may issue commands to increase or decrease the level of encryption as you see fit. If you experience firewall issues, you often need to have your control channel transmit "in the clear" so your firewall can observe it and dynamically open ports on demand. You may also drop out of encryption for the data channel, which will increase the speed of transmission and reduce the load on your CPU. The unfortunate side effect, however, is that I will kill you in your sleep for doing that. I haven't bothered to look into the TELNET side of things because I only use it for 3270 and within our private network. - Scott On Tue, Jan 5, 2010 at 9:54 AM, Jerry Whitteridge < [email protected]> wrote: > Unfortunately the DSS requires 2 things. 1) that PAN data be encrypted > during transmission. 2) That credentials are not sent in clear as these can > be then used to access the platform and then attempt to access the data. > > As both FTP and Telnet send credentials in clear their protocols have to be > encrypted to satisfy 2) thereby requiring ALL FTP and Telnet to be > encrypted. (Or at least that has been how our varying QSA's have explained > it to me). > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of Scott > > Sent: Tuesday, January 05, 2010 9:48 AM > > To: [email protected] > > Subject: Re: PCI and Auditors perceptions thereof > > > > Well, it makes sense to me that it specifies PAN data (and > > probably CVV2, pins, yadda). I should really take the time > > to read the PCI-DSS, but I have the attention span of a > > newborn puppy. The only requirement is really for "strong > > cryptography" which, in the context of PKI, is 1024 bit or greater. > > > > Mostly I think these standards are written in a way that is > > just vague enough to make my life a living hell. I really > > wish "when in doubt, encrypt" would be codified in everything > > so I could recover a measurable portion of my lifespan from > > all the meetings. > > > > Generally, I really like TLS. However, FTPS is (by far) the > > worst mechanism to come out of the last decade. If you don't > > care about providing your own certificate, it's pretty > > simple. But when you depend on FTP+TLS, life becomes > > miserable because it's neither trivial nor commonplace. > > > > </Rant> > > > > Yours, > > Scott > > "Email Firewall" made the following annotations. > > ------------------------------------------------------------------------------ > > Warning: > All e-mail sent to this address will be received by the corporate e-mail > system, and is subject to archival and review by someone other than the > recipient. This e-mail may contain proprietary information and is intended > only for the use of the intended recipient(s). If the reader of this > message is not the intended recipient(s), you are notified that you have > received this message in error and that any review, dissemination, > distribution or copying of this message is strictly prohibited. If you have > received this message in error, please notify the sender immediately. > > > ============================================================================== > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
