> On Jan 25, 2018, at 11:37 AM, David Precious wrote:
>
> then that uses LWP::UserAgent under the hood for the communication with
> authorize.net; it doesn't set any SSL/TLS-specific options when calling
> LWP::UserAgent, unless you're causing it to yourself.
>
> LWP::UserAgent will use LWP::Pro
On Thu, 25 Jan 2018 10:19:26 -0800 SurfShop
wrote:
> I keep getting emails from Authorize.net about their upcoming
> disablement of TLS 1.0 and TLS 1.1 and I need to know if that has
> anything to do with Perl or not. I don't have any code in SurfShop
> that references either SSL or TLS, s
> On Jan 25, 2018, at 10:43 AM, Darryl Philip Baker
> wrote:
>
> If you do not know TLS 1.0 and TLS 1.1 have a vulnerability in the design of
> the protocol and they are being deprecated. Currently only TLS 1.2 now and
> TLS 1.3 when finalized are considered safe. TLS 1.2 was defined in August
TLS is handled in the connection. So if your Perl code is opening the
connection directly it would be in the SSLeay module and OpenSSL libraries. If
your Perl cod is behind a webserver it is the webserver that handles the
connection. Only if your Perl code is being distributed to others to run w
If you do not know TLS 1.0 and TLS 1.1 have a vulnerability in the design of
the protocol and they are being deprecated. Currently only TLS 1.2 now and TLS
1.3 when finalized are considered safe. TLS 1.2 was defined in August of 2008
so if you are using anything developed in the last five years
I keep getting emails from Authorize.net about their upcoming
disablement of TLS 1.0 and TLS 1.1 and I need to know if that has anything to
do with Perl or not. I don't have any code in SurfShop that references either
SSL or TLS, so maybe that's handled by Perl itself or a module I'm us
