Grant Taylor wrote: >I'd have to refresh myself on how granular you can target things, but I >believe you can definitely differentiate between NFS, HTTP, MQ, JDBC, >ODBC, Enterprise Extender, and any other protocols you're using based on >the different ports that they operate on.
Perhaps you can...and that may not actually matter very much in this context. It might make network-related security practices a little more complicated, though. How much complexity do you want? :-) >I get the impression that you're thinking a more traditional /tunnel/ >connection with different (inside) tunnel IPs at each end. I'm talking >about /transport/ mode, which is explicitly between two end system IPs. >I'm also assuming that it's possible to have different security >associations per source IP, destination IP, source port, and destination >port tuples. Thus TN3270E Session A would be in a different >cryptographic zone from TN3270E Session B to the same endpoint. Other >protocols / services would also be in different cryptographic zones. First of all, (purported) source IP and port don't offer anything except a minor speed bump, if that. Hypothetically you *could* do this, but I have the same question about complexity. Complexity itself can make it more difficult to achieve a particular security outcome. I'm not sure what problem(s) you're trying to solve here. TLS-encrypted TN3270E works *really* well -- not to the exclusion of other available options and practices, of course. I wrote: >There's nothing wrong with double, triple, or even quadruple encryption! Grant replied: >I disagree. Each layer of encryption (or more generically, tunneling) >introduces it's own overhead and consumes usable space in packets, thus >requiring more packets to get the same amount of data from end to end. >There are many factors that come into play as to if this overhead causes >problems or not. OK, but "most often not" and, as time marches on, "progressively less often than most often not." Programming with two digit years made some sense back when each digit's worth of storage was precious. We don't live in that world any more and haven't for a long, long time. Likewise, we don't live in a world of expensive encryption any more. In all likelihood your mobile phone is quadruple encrypting certain data, after all. I'm highly confident the vast majority of installations can easily (and probably often should) double encrypt TN3270E traffic (TLS-encrypted TN3270E and VPN). If you're working on a project involving a High Frequency Trading (HFT) over TN3270E communication system, then we *might* have something(s) to talk about here. :-) I wrote: >That's subpar because you're knocking the user out of the security >equation. End user collaboration is really important to maintain a good >or better security posture. Grant replied: >I've found that relying on the end user for security to be a weaklink in >the chain. I would *much* rather rely on technology to enforce the >security. Who said anything about *relying* on end users? I pointed out, correctly, that there's danger in *excluding* end users from participating in security defense. They often raise the first alarms. The more security allies, the better. Engineering something that assures padlocks never appear on their emulator session windows is...not good. Also bear in mind that encryption/decryption isn't the only thing TLS provides. It also provides server and/or client certificate authentication, also surfaced to the end user typically in the form of a padlock and/or error messages/halts if the certificate authentication fails. All great stuff from a security point of view. If there's a DNS hijack, IP redirection, miskeyed address, etc., etc., all bets are off without TLS certificate authentication. Conceivably you could "hardwire" the client to a VPN and adopt particularly rigid routing and addressing rules (in a 10.x.y.z network for example), and that might help to some degree, but...what problem(s) are we trying to solve again? :-) I wrote: >Anyway, in summary, if you haven't already, get AT-TLS-encrypted >TN3270E turned on, and shut off the unencrypted stuff. You've been able >to avoid this class of security risks for literally a quarter century, >and it's way, way past time to avoid them if you haven't already. Grant replied: >Sure. Hurray! - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
