TLS and Perl

[SurfShop]

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 using like SSLeay.

Is there a write up on this anywhere? I've searched for Perl and TLS but I haven't found anything that answers my question. I'm not familiar with this side of things and I don't want orders to stop being processed in the cart when they switch over, so I'm hoping someone knows more about this than I do.

Thanks,
Frank

[Darryl Philip Baker]

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 it should support TLS 1.2.

Darryl Baker
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL 60201-3715
darryl...@northwestern.edu
(847) 467-6674

--
To unsubscribe, e-mail: beginners-...@perl.org
For additional commands, e-mail: beginne...@perl.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.perl.org_&d=DwIFAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=tdje61_VHSXp608oLofeaJnnzo2Sr9_Cdcp70bBEtQ8&m=spLFHsoESwLJ5AJkeI0RU2vWyyiJAdn9Z7BaDTsl1gc&s=n-y-ZZg_ug39BomX0aKk1IsNnPfHE1dYC4b7yJEXD1E&e=

[Darryl Philip Baker]

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 will you care what version of Perl others are running.

Darryl Baker
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL 60201-3715
darryl...@northwestern.edu
(847) 467-6674

On 1/25/18, 1:12 PM, "SurfShop" <contac...@surfshopcart.com> wrote:

> On Jan 25, 2018, at 10:43 AM, Darryl Philip Baker <darryl...@northwestern.edu> 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 of 2008 so if you are using anything developed in the last five years it should support TLS 1.2.

Thanks, Darryl. Yes, that much I do know about TLS. I just didn't know if I needed to update anything on my end in the code. I don't want a bunch of angry emails from customers saying their cart's broken the day after the switch. ;) From your answer, it doesn't sound like I need to change anything.

However, what if someone is still on Perl 5.8.8? That's older the last 5 years. Will that even make a difference? Where is TLS actually handled - in Perl, in the code, in the browser, on the server? This is the part that has me stumped.

Thanks again,
Frank

[David Precious]

On Thu, 25 Jan 2018 10:19:26 -0800 SurfShop
<contac...@surfshopcart.com> 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, so maybe that's handled by Perl
> itself or a module I'm using like SSLeay.

Well, how do you interact with Authorize.net?

For instance, if you use Business::AuthorizeNet::CIM to deal with them,
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::Protocol::https to talk to remote
servers over SSL, using either IO::Socket::SSL or Net::SSLeay under the
hood.

In the absence of any specific instructions otherwise (which B::A::CIM
doesn't provide), IO::Socket::SSL will use a sane, secure set of
ciphers.

If LWP::UserAgent is using IO::Socket::SSL, then setting
$IO::Socket::SSL::DEBUG to a suitable value should let you see what
it's doing, and what ciphers it negotiates IIRC.

If you've made use that the openssl library and the above-mentioned
modules are up to date, you're likely to be fine.

I do believe they disabled TLS 1.0 on their testbed in advance though,
so to be confident, point your code at their testbed and check that it
works - if so, all is well!

[SurfShop]

> On Jan 25, 2018, at 10:43 AM, Darryl Philip Baker <darryl...@northwestern.edu> 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 of 2008 so if you are using anything developed in the last five years it should support TLS 1.2.

[SurfShop]

> On Jan 25, 2018, at 11:37 AM, David Precious <dav...@preshweb.co.uk> 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::Protocol::https to talk to remote
> servers over SSL, using either IO::Socket::SSL or Net::SSLeay under the
> hood.

Perfect! Thanks, David. That's exactly what I needed to know.

Frank