Hi List, Does anyone know why the above URL is still using TLS V1.0. I can't connect to it unless I enable TLS V1.0 which I was under the impression that it should not be used anymore. Thanks for any enlightenment. Steve --
Stop paranoia? Tlsv1.0 is not recommended when storing credit card data. Eero Hi List, Does anyone know why the above URL is still using TLS V1.0. I can't connect to it unless I enable TLS V1.0 which I was under the impression that it should not be used anymore. Thanks for any enlightenment. Steve -- _______________________________________________ CentOS mailing list CentOS at centos.org https://lists.centos.org/mailman/listinfo/centos
On Fri, 25 Mar 2016 16:50, Eero Volotinen wrote:> > Stop paranoia? Tlsv1.0 is not recommended when storing credit card data. > > Eero > Hi List, > > Does anyone know why the above URL is still using TLS V1.0. > > I can't connect to it unless I enable TLS V1.0 which I was under the > impression that it should not be used > anymore. > > Thanks for any enlightenment. > > Steve@Eero: IMHO you are missing some points here. There are more and more browsers that are unable to use SSL{2,3} as well as TLS1.0, not just disabled via config, but this decission was made at compile time. Newer Android and Apple-iOS devices for example. And the point is not that the site supports TLS1.0, but that it does not support TLS1.1 and/or TLS 1.2, and as such is incassessible to devices that ask for TLS1.1 as minimum for HTTPS. But that is for the admins/webmasters of the servers to resolve. - Yamaban
On 03/25/2016 08:08 AM, Steve Clark wrote:> Hi List, > > Does anyone know why the above URL is still using TLS V1.0. > > I can't connect to it unless I enable TLS V1.0 which I was under the > impression that it should not be used > anymore. > > Thanks for any enlightenment. > > SteveTLS 1.0 is still safe but the server should upgrade to allow TLS 1.2 For my more sensitive servers I only allow TLS 1.2 because every modern browser supports it, so there isn't a justification for still allow TLS 1.0 as it is always possible there is a zero-day.
On 25/03/16 16:08, Steve Clark wrote:> Hi List, > > Does anyone know why the above URL is still using TLS V1.0. > > I can't connect to it unless I enable TLS V1.0 which I was under the impression that it should not be used > anymore. > > Thanks for any enlightenment. > > Steve >Something that is already on the TODO list, as that's actually the only remaining CentOS 5 node, reason why it doesn't support something higher than tls 1.0 The whole setup will be reinstalled/migrated to c7 in the following weeks (time permitting). -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20160329/a1a4fb7b/attachment-0001.sig>
On 29/03/16 18:09, Fabian Arrotin wrote:> On 25/03/16 16:08, Steve Clark wrote: >> Hi List, >> >> Does anyone know why the above URL is still using TLS V1.0. >> >> I can't connect to it unless I enable TLS V1.0 which I was under the impression that it should not be used >> anymore. >> >> Thanks for any enlightenment. >> >> Steve >> > > Something that is already on the TODO list, as that's actually the only > remaining CentOS 5 node, reason why it doesn't support something higher > than tls 1.0 > The whole setup will be reinstalled/migrated to c7 in the following > weeks (time permitting). >Just to close that thread : migration of the website/forums was announced and scheduled for today, and it went live earlier today. So now you should be able to use TLSv1.2 -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20160406/22ec09dd/attachment-0001.sig>