GitLab schaltet den Support für TLS 1.0 und 1.1 ab
Aus Sicherheitsgründen lassen sich GitLab.com und sowie die GitLab API ab 15. Dezember 2018 nur noch mit mindestens TLS 1.2 verwenden.
![Versionsverwaltung: GitLab 9.2 freigegeben](https://heise.cloudimg.io/width/610/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/2/5/4/2/1/3/0/dig-3a42c0a36d7134ef.jpeg)
Der quelloffene Repository-Verwaltungsdienst GitLab hatte bereits im Oktober per Blog-Post angekündigt, die Unterstützung für Transport Layer Security (TLS) in den Versionen 1.0 und 1.1 bis zum Jahresende einzustellen. Nachdem die Vorbereitungen, die Nutzern von GitLab.com und der GitLab API einen weitestgehend problemfreien Wechsel auf TLS 1.2 ermöglichen sollen, offenbar planmäßig verlaufen, steht nun der 15. Dezember als Stichtag für das Supportende von TLS 1.0 und 1.1 fest.
Unter anderen im Zuge der anhaltenden Bedrohungen durch die OpenSSL-Lücke Heartbleed hatten die GitLab-Betreiber einen Fahrplan mit Maßnahmen zur Verbesserung der Sicherheit auf der Plattform aufgelegt. Dadurch will GitLab auch schnellstmöglich sicherheitsrelevanten Compliance-Anforderungen wie dem Payment-Card-Industry-Standard (PCI) DSS 3.1 gerecht werden, der stärkere Kryptografie verlangt, als sie in Secure Sockets Layer (SSL) 3.0 oder TLS 1.0/1.1 vorgesehen ist.
Nach Einschätzung der Verantwortlichen bei GitLab soll der Großteil des Traffics auf der Plattform nicht vom Wechsel auf TLS 1.2 beeinträchtigt werden, da die Mehrheit der Clients bereits mit dieser Version der Transport Layer Security arbeite. Zu den auf Clientseite notwendigen Updates, um Kompatibilität mit TLS 1.2 sicherzustellen, seien beispielhaft Folgende erwähnt: JDK 6, VisualStudio 2017 und Red Hat 6.8 oder 7.2. Beim Git-Credential-Manager-for-Windows ist mindestens Version 1.14.0 erforderlich. Für Browsertests oder auch das Prüfen von Integrationen, die API-Tokens oder Scripting verwenden, steht GitLab-Anwendern die Canary-Produktionsumgebung als Testplattform zur Verfügung. (map)