Amazon AWS und Sicherheit

Archiv
1

Hallo zusammen, bin noch ganz neu bei Tomorrrow :slight_smile:

Jedenfalls sind mir ein paar Sachen aufgefallen.
Tomorrrow benutzt AWS in Frankfurt von Amazon als Cloud-Computing-Plattform. Hierbei sollte man bedenken, dass AWS in Frankfurt zu diesem Zeitpunkt noch nicht auf Ökostrom setzt, steht sogar direkt auf der Sustainability-Seite von Amazon Web Services. Zwar sagt Amazon aus, dass dies nachträglich ausgeglichen wird, aber das geht sicherlich besser. Es gibt durchaus Alternativen (beispielsweise Hetzner), die von Anfang an auf Ökostrom setzen und abgesehen davon nicht das fragwürdige Image von Amazon haben.

Der nächste Punkt ist eher sicherheitsrelevant und zwar ist mir aufgefallen dass der API-Server (api.tomorrow.one), mit dem ja auch die App kommuniziert, nicht wirklich den best practices der Sicherheit entspricht. Der API-Server unterstützt aktuell die Verschlüsselungsstandards TLS 1.0, TLS 1.1 und TLS 1.2. TLS 1.0 ist ein Standard von 1999 und wird mittlerweile als unsicher eingestuft. Der wirklich aktuelle Standard TLS 1.3 wird hingegen nicht unterstützt. Aber warum? Die Android-App von Tomorrow ist sowieso erst ab Android 5.0 kompatibel und die iOS-App ab iOS 11. Diese Versionen beider Betriebssysteme sowie selbstverständlich alle nachfolgenden Versionen haben kein Problem mit TLS 1.2, dementsprechend sollte es keinen Anwendungsfall geben, bei dem der Gebrauch dieser alten TLS-Standards nötig wäre.

Abgesehen davon könnte man ja mit gutem Beispiel vorangehen und DNSSEC aktivieren, was ja kein Problem darstellen sollte. Weniger sicherheitsrelevant, aber aus Kompatibilitätsgründen wäre es auch schön wenn die API auch per IPv6 ansprechbar wäre um bessere Stabilität bei Dual-Stack-Lite Internetverbindungen mit Carrier-NAT zu gewährleisten.

Ich bin mir nicht sicher zu welchem Ausmaß diese Änderungen von SolarisBank abhängen, aber wäre schön wenn diese Punkte verbessert werden könnten, ansonsten bei Unklarheiten einfach fragen :slight_smile:

9 „Gefällt mir“
2

Ich habe den Satz falsch verstanden, er hat TLS1.2 enabled, aber du meinst warum man es nicht nur bei TLS 1.2 belässt… :upside_down_face:

1 „Gefällt mir“
4

Vermutlich, ja, da es eben keinen Anwendungsfall gibt, in welchem man 1.0 und 1.1 braucht und es sogenannte „Downgrade Attacks“ gibt, bei welchem ein MITM-Angreifer, den Server dazu bringen kann mir dem Nutzer einen geringeren Sicherheitsstandard auszuhandeln, obwohl der Nutzer nach einer neueren Version gefragt hat, um somit dann Sicherheitslücken in geringeren Versionen ausnutzen zu können.

1 „Gefällt mir“
5

Genau so war es gemeint, sorry falls das nicht ganz so verständlich formuliert war. TLS 1.0 ist hierbei das größere Problem, es ist eben ein Standard der über 20 Jahre alt ist und diverse Schwächen zeigt.

Allerdings sollte der API-Server so konfiguriert werden, dass er TLS 1.2 und TLS 1.3 unterstützt, da TLS 1.3 seit 2018 kein „Draft“ ist und seitdem auch standardisiert ist. Übrigens ist die Deaktivierung von TLS 1.0 (und idealerweise auch von TLS 1.1) seit 2018 Pflicht um PCI-DSS-Compliance-Kriterien zu erfüllen, welche zwar hauptsächlich für E-Commerce gedacht sind, aber für eine Bank auch nicht ganz irrelevant sind.

5 „Gefällt mir“
6

https://www.ssllabs.com/ssltest/analyze.html?d=api.tomorrow.one&latest

Ausser TLS 1.0 und 1.1 sieht’s gar nicht so schlecht aus.

Wegen grünem Hosting: Ja, Amazon ist da nicht ideal, aber in einer großen Cloud-Umgebung hat man sicher bessere Building Blocks (z.B. Lambda functions, Datenbanken) als bei Hetzner, wo man IMHO nur Rechner/VMs kreieren kann. So kann man in AWS oder vergleichbaren Clouds schneller entwickeln. Mag auch ein Faktor sein. Aber Microsoft Azure und die Google Cloud sind grüner als AWS, d.h. Verbesserungspotenzial ist da. Ein Umbau ist jedoch bestimmt nicht trivial.

2 „Gefällt mir“
7

Zum Hosting: erstmal danke für den Link zu Greenpeace, @ole! Bei diesem Review von wired (12/2019) kommen Google und Microsoft auch deutlich besser weg als Amazon (Google noch etwas besser als Microsoft): Amazon, Google, Microsoft: Here's Who Has the Greenest Cloud | WIRED

Einen interessanten Punkt finde ich auch, dass die Nutzungseffizienz von Servern in der Cloud bei ca 65% im Vergleich zu 15% On Premise liegen soll: https://www.goclimateneutral.org/blog/the-carbon-footprint-of-servers/

Mich würde ja mal interessieren, welche Hoster andere grüne Techies hier verwenden, wenn sie Sachen wie Datenbank, Kubernetes, Pub/Sub, Backups, hochverfügbare Infrastruktur etc „aus der Steckdose“ nutzen wollen (weil sie kein riesiges Plattform Team am Start haben was den ganzen Kram betreiben kann)…?

Und wie sehen andere AWS/GCP/Azure im Vergleich?

3 „Gefällt mir“
8

Im Vergleich zur N26 (A+, DNS CAA) aber auch im Vergleich zu diversen traditionelle Banken wie den Volksbanken oder Sparkassen ist das Ergebnis ernüchternd. Schließlich geht es hier um Geld und es ist wirklich kein komplexes Problem. Außerdem bringt es mich zumindest zum Grübeln wenn selbst so einfache Sachen nicht vernünftig implementiert werden.

Und ja, was Flexibilität anbelangt ist AWS natürlich super, aber prinzipiell ist es eine Frage des Ansatzes zum Entwickeln, ich selbst bin der Überzeugung dass man wenigstens versuchen sollte möglichst ohne vendor lock-ins zu entwickeln, wobei das bei solch großen Projekten natürlich schwieriger ist. Außerdem benutze ich selbst AWS wirklich ungern, Traffic ist meines Erachtens zu teuer und IPv6 ist miserabel implementiert - die Marktdominanz würde ich teils auf den Hype zurückführen, für viele Unternehmen gibt es deutlich bessere Alternativen.

Zum Thema der on-premise efficiency sollte man auch in Betracht ziehen dass der Report aus dem Jahr 2014 stammt. Da hat sich auf jeden Fall was getan, selbst Firmen die auf on-premise angewiesen sind können/wollen sich solche Mehrkosten nicht leisten.

Was meine eigene Infrastruktur anbelangt, ja, ich habe natürlich Server von OVH und das ohne schlechtes Gewissen. OVH hat unteranderem durch das Geschäftsmodell bedingt sehr gute PUE-Werte und Kernkraft ist wenigstens CO2-arm. Ansonsten kann ich auch Hetzner empfehlen, sowohl in Finnland als auch in Deutschland.

9

Da habe ich ein paar Unklarheiten, da Server Security nicht ansatzweise mein Fachgebiet sind :smile:, wäre nett wenn mir einer das Problem erklärt.

Ok von AWS, bzw. Amazon allgemein, halte ich nicht viel von. Meine Server selbst hoste ich z.B. ebenso bei webgo und OVH.

Ohne jetzt spezielles Wissen vorweisen zu können würde mich aber sicherheitstechnisch interessieren, was an AWS das Problem ist?

  • Kann AWS kein TSL1.3?
  • Gibt es Downgrade Attacks welche das Device Binding theoretisch umgehen könnten?
  • Ist TLS1.2 nicht erstmal “ausreichend”?
  • Was bietet uns als Kunde DNSSEC? Laut meinem Verständnis ist dies doch gar nicht so einfach ein zu binden, wenn die Server ja teilweise von AWS kommen, solarisBank-Server und dann noch die von der Tomorrow App auf dem AWS Server?
  • Was meinst du mit der IPv6-API? IPv6 hat ja einer der vielen Vorteile das NAT eigentlich nicht mehr von Nöten ist, und wenn dann höchstens noch als Carrier Grade NAT die Grenzen der IPs übersetzt. Laut meinem Verständnis liegt der größte Vorteil von IPv6 aber im Bereich des IoT.

Würde mich über antworten freuen, die mein Verständnis dafür außerhalb von googeln und ein paar Kenntnissen in dem Bereich erweitern.

Schönen späten Abend euch ansonsten schon mal :slight_smile:

10

Dir auch einen schönen (sehr) späten Abend, Tobias :slight_smile:
Ich selbst führe keine Audits durch, aber zumindest etwas kann ich zum Thema beitragen.
tldr: AWS ist nicht unbedingt das Problem, da ging es mir eher um Nachhaltigkeit und den generellen Ruf von Amazon.

TLS wird serverseitig auf Software-Ebene implementiert, daher ist es hierbei irrelevant ob bei AWS gehostet wird oder nicht. Die API von Tomorrow läuft auf nginx (zumindest als reverse proxy) und nginx unterstützt seit geraumer Zeit TLS 1.3. Wäre also prinzipiell nur eine Frage der Konfiguration.

Aktuell nicht, aber alleine die serverseitige Unterstützung von TLS 1.0 ist eine Schwäche in der Verschlüsselung. Der einzige Grund veraltete TLS-Versionen zu unterstützen ist zwecks Kompatibilität, aber diese Vorraussetzung ist nicht erfüllt, da es kein Gerät gibt welches die Tomorrow-App ausführen kann, aber gleichzeitig keine Unterstützung für TLS 1.2 bietet. Das ist eben das was mich stutzig macht, warum macht man sowas bloß? Best practices für TLS sind mehr als ausreichend dokumentiert (vereinfacht z.B. hier oder hier).

Ja, ist es, aber TLS 1.3 bringt auch ziemlich signifikante Verbesserungen, vor allem bei Performance aber auch bei besseren und zukunftssichereren Ciphers. Es gibt keinen wirklichen Grund TLS 1.3 nicht zu unterstützen. Auch hier ist der entscheidende Faktor der HTTP(S)-Server und dessen Konfiguration, in diesem Fall nginx wie vorhin erwähnt. nginx unterstützt TLS 1.3 seit April 2017. Rein hypothetisch würde für die Deaktivierung von TLS 1.0 und TLS 1.1 sowie Aktivierung von TLS 1.3 eine einzige Zeile in der nginx-config reichen:

ssl_protocols TLSv1.2 TLSv1.3;

Uff :sweat_smile: Uns Kunden direkt erstmal gar nichts, aber es ist eine weitere Verifizierungsebene. Für den Kunden ist ja lediglich der API-Server von Tomorrow im Moment relevant, da soweit ich weiß vom Smartphone nur dieser angesprochen wird. Die Verifizierung findet dann nicht von der Tomorrow-App statt (außer bei hardcoding von DNS resolvern, wie beispielsweise bei der Netflix-App auf Android), sondern vom DNS-Resolver, der im Falle eines Mismatch gar nicht erst die IP-Adresse weitergibt und damit die gekaperte Verbindung kappt. Implementiert wird es auf dem Domain-Nameserver und beim Domain-Registrar. Tragischerweise setzt Tomorrow auf GoDaddy als Registrar und GoDaddy scheint bei .one-Domains DNSSEC nicht zu unterstützen, was wirklich willkürlich ist, da die .one-TLD DNSSEC sehr wohl unterstützt. Als Nameserver wird Amazon Route53 verwendet, ist an sich nicht verkehrt, auch wenn es meines Erachtens bessere Alternativen gibt. DNSSEC wird von Route53 jedenfalls unterstützt. Vorrausgesetzt dass es diese willkürliche Einschränkung bei GoDaddy nicht gäbe oder Tomorrow auf einen solideren Registrar setzen würde, dann ist DNSSEC eine Frage der einmaligen und dennoch einfachen Implementierung.

Es gibt mittlerweile in Deutschland aber auch in anderen Ländern genug Internetanschlüsse die auf Dual-Stack-Lite setzen (d.h. CGNAT IPv4 + nativ IPv6) und wenn Tomorrow nativ auch IPv6 unterstützen würde, dann kann die Verbindung zwischen Smartphone und Tomorrow auch auf der nativen Ebene ohne NAT bleiben. Leider gibt es viele Implementierungen von CGNAT die viele Probleme mit sich bringen und keepalive beeinflussen. Außerdem geht es wirklich auch um das Prinzip, IPv4 ist mittlerweile ein zusammengebasteltes Konstrukt, welches dem aktuellen Stand der Dinge nicht entspricht. Leider zieht sich die Implementierung von IPv6 und jeder Stakeholder, sei es Internetprovider, Routerhersteller oder Webhoster, ist automatisch ein Teil des Problems wenn solche Themen ignoriert werden. Man sollte auch bedenken dass Apple bei iOS-Apps seit einiger Zeit Unterstützung für IPv6-only vorraussetzt. Jedenfalls kann ich hier auch aus meiner Perspektive sprechen, ich würde seit einigen Jahren nie ein Projekt ohne IPv6-Support abliefern und die meisten Argumente die genannt werden, sind eher schlechte Ausreden. Auch hier ist AWS ein Teil des Problems, da bei EC2-Instanzen die IPv6-Unterstützung eher mühsam und frustrierend ist. Bei anderen AWS-Diensten, wie beispielsweise Lightsail gibt es keinen IPv6-Support, was gewissermaßen die Einstellung von Amazon gegenüber IPv6 klarstellt…

Ich hoffe jedenfalls dass das einige Fragen beantwortet und falls es noch weitere Fragen gibt, dann werde ich versuchen diese ebenfalls zu beantworten.

2 „Gefällt mir“
11

Beim Thema Vendor Lock-in bin ich ganz bei Dir, das sollte man vermeiden.
Aus meiner Sicht heißt das, auf AWS z. B. nicht Kinesis zu benutzen (AWS proprietärer Dienst), sondern z. B. Kafka (Open Source), was in anderen Umgebungen genauso nutzbar wäre.
Der Vorteil der großen Cloud Anbieter ist ja, dass sie viele Dienste wie hoch verfügbare Datenbanken, managed Kubernetes, Backup etc mitbringen, also nicht nur IaaS sondern auch PaaS Features. Diese Plattform Dienste selbst aufzubauen und in der gleichen Qualität zu betreiben ist leider immer deutlich teurer, als die Sachen einzukaufen. Zumindest war das in den Kontexten, wo ich unterwegs war/bin immer so (wo mehrere Teams verschiedene Services / Systeme bauen, und wo komplexere Dinge wie z. B. Kafka, Cassandra oder Kubernetes im Spiel sind).

2 „Gefällt mir“
12

Danke für die netten Erklärungen und auch von @martin.grotzke :nerd_face::blush:

Verstehe ich richtig, dass der Ursprung der aufgelisteten Probleme AWS/Amazon zwecks Vendor-Lock-Ins und Restriktierung ist?

Bei den „niedrigen TLS-Versionen“ kann ich mir vorstellen, dass diese von Anfangsversion der Entwicklung mit älteren Handy- und Tablet-Modellen ein herkommen

13

Hallo,

ich möchte einmal auf diesen Artikel hier hinweisen: https://www.zdnet.com/article/browsers-to-block-access-to-https-sites-using-tls-1-0-and-1-1-starting-this-month/

2 „Gefällt mir“
14

da es um die Kommunikation zwischen App und Server geht, dürfte das hier nicht relevant sein. Außer vielleicht um denk Punkt deutlich zu machen, dass TLS 1.0 und 1.1 veraltet sind und nicht aktiviert sein sollten.

1 „Gefällt mir“
15

Ja, so war es gemeint.

16

@jtbrinkmann und @All hier: Die Tomorrow App macht inzwischen nur noch TSL1.2+ und kein TSL 1.0 mehr. Damit sehen auch die Testergebnisse top aus: SSL Server Test: api.tomorrow.one (Powered by Qualys SSL Labs)

Liebe Grüße aus Hamburg

13 „Gefällt mir“
17

Super! Danke für das Update.

2 „Gefällt mir“
18

Bisschen spät meinerseits, aber dennoch danke für das Update!
Jetzt hoffe ich nur noch auf die Verwendung einer nachhaltigeren Cloud-Computing-Plattform wie Oracle statt AWS aber das ist schon ein deutlich größerer Schritt :slight_smile: