ADSM-L

Re: [ADSM-L] 7.1.8/8.1.3 Security Upgrade Install Issues

2017-10-10 10:04:01
Subject: Re: [ADSM-L] 7.1.8/8.1.3 Security Upgrade Install Issues
From: "Sergio O. Fuentes" <sfuentes AT UMD DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 10 Oct 2017 10:00:09 -0400
I have one other question for any IBMers or people who may have had
experience with this:

If 8.1.2 clients can negotiate certificates with a 8.1.3 TSM server, does
this mean that for users who use third-party signed certificates (not
loaded by default in the TSM client) that the certificate chain will
automatically be loaded to an 8.1.2 client?  For example, we use digicert
signed certs. Digicert is not one of the pre-loaded root certificates in
the TSM client (Verisign and Thawte are).  Can an 8.1.2 client negotiate
the entire cert chain or will we be required to load the root and
intermediate digicert certs into the client?

To ask more directly, how can I petition IBM to release a client with
pre-loaded DigiCert CA certificates?

Thanks!
Sergio

On Mon, Oct 9, 2017 at 12:14 PM, Skylar Thompson <skylar2 AT u.washington DOT 
edu>
wrote:

>  Content preview:  I definitely agree with this; at least for TSM v7 it
> would
>     have been far better to call it v7.2.0 to make it clear that it's a
> huge
>    change with lots of caveats and potential failure points. We've just
> now discovered
>     that TSM v7.1.8 does not play nicely with GPFS/mmbackup due to a
> change in
>     how SSL certificates are loaded - hopefully it's a simple fix but who
> knows...
>     [...]
>
>  Content analysis details:   (0.7 points, 5.0 required)
>
>   pts rule name              description
>  ---- ---------------------- ------------------------------
> --------------------
>   0.7 SPF_NEUTRAL            SPF: sender does not match SPF record
> (neutral)
>  -0.0 RP_MATCHES_RCVD        Envelope sender domain matches handover relay
> domain
> X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134]
> X-Barracuda-Start-Time: 1507565699
> X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
> X-Barracuda-URL: https://148.100.49.27:443/cgi-mod/mark.cgi
> X-Barracuda-Scan-Msg-Size: 1182
> X-Virus-Scanned: by bsmtpd at marist.edu
> X-Barracuda-BRTS-Status: 1
> X-Barracuda-Spam-Score: 0.00
> X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of
> TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=
> X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.43739
>         Rule breakdown below
>          pts rule name              description
>         ---- ---------------------- ------------------------------
> --------------------
>
> I definitely agree with this; at least for TSM v7 it would have been far
> better to call it v7.2.0 to make it clear that it's a huge change with lots
> of caveats and potential failure points. We've just now discovered that TSM
> v7.1.8 does not play nicely with GPFS/mmbackup due to a change in how SSL
> certificates are loaded - hopefully it's a simple fix but who knows...
>
> On Sat, Oct 07, 2017 at 02:36:13PM -0500, Roger Deschner wrote:
> > This difficulty comes up while there are open, now-published security
> > vulnerabilities out there inviting exploits, and making our Security
> > people very nervous. But the considerations described in
> > http://www-01.ibm.com/support/docview.wss?uid=swg22004844 make it very
> > difficult and risky to proceed with 7.1.8/8.1.3 as though it was just a
> > patch. It's a major upgrade, requiring major research and planning, with
> > the threat of an exploit constantly hanging over our heads. I really
> > wish this had been handled differently.
>
> --
> -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> -- Genome Sciences Department, System Administrator
> -- Foege Building S046, (206)-685-7354
> -- University of Washington School of Medicine
>


ADSM.ORG Privacy and Data Security by KimLaw, PLLC