Since a lot of chips a manufactured in China, a device could be sending China your data, which is why Huawei is being banned from communications networks.
On Thu, Jul 22, 2021 at 7:09 PM Charles Mills <charl...@mcn.org> wrote: > > Guys, this is the problem with inventing your own solution. > > Public keys are, well, public. You can transfer them over an insecure medium. > You can put them on your Web site. You can announce them over the PA. The TLS > protocol transfers public keys over the communication link before it is > trusted. > > > If the OP can't safely get a public [key] copied between LPARs / CECs in a > > trusted network > > The new fashion in fact is to NOT trust internal networks. You really don't > know how far an intruder may have intruded, so you should assume every > communication channel is insecure. In the new era of cloud and partners and > bring your own device, exactly what is an internal and what is an external > network? (This new paradigm is called "Zero Trust." > https://csrc.nist.gov/publications/detail/sp/800-207/final. I have a > presentation on Zero Trust coming up courtesy of New Era, but we don't have a > date yet. A good month or so out.) > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Grant Taylor > Sent: Thursday, July 22, 2021 4:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: How should I send file to another sysplex securely. > > On 7/22/21 3:17 PM, Paul Gilmartin wrote: > > It lacks authentication and does not prevent MITM attacks: > > I think we might be talking about two slightly, but distinctly, > different scenarios. > > I took the OP's statement to be talking about needing to move data from > one LPAR / CEC on the left side of the room to another LPAR / CEC on the > right side of the room. Wherein the room and the network are trusted; a > la. internal company network. > > What's more is I was anticipating the OP to be performing all of the > steps. As such, the OP could validate that the public key copied from > the destination system to the source system was in fact one in the same. > Be it byte for byte comparison of hex output, or comparison of > cryptographic hashes, or even IND$FILE transfers from the destination > system to the source system via the common workstation / terminal emulator. > > Aside: If the OP needs to do the transfer in conjunction with a fellow > SYSOP from elsewhere in the world, they can get on the phone with each > other (or use some other out of band communications method that they > trust) to confirm public key. > > Further aside: If the OP can't safely get a public copied between LPARs > / CECs in a trusted network, then s/he has bigger problems. If > interlopers are messing with such a transfer, ... that's a *LOT* bigger > problem. Problems big enough that asking for help on a mailing list is > quite likely not sufficient. > > > > -- > Grant. . . . > unix || die > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
