AWS S3 Deaktivieren der SSLv3-Unterstützung

Question

Wir haben eine E-Mail von AWS erhalten, in der im Wesentlichen steht: "S3 deaktiviert den SSLv3-Support, der Zugriff wird in 15 Tagen unterbrochen". Dann listeten sie einige Buckets auf, die wir haben (eine in der Produktion), die derzeit Anfragen von Clients akzeptieren, die SSLv3 angeben. Die vollständige E-Mail ist hier, und andere AWS Benutzer scheinen ein zu erhalten haben:

https://gist.github.com/anonymous/4240c8af5208782c144c

Meine Frage ist, wie wir für dieses Szenario zu testen, und was brauchen wir für dieses cut- vorzubereiten zu tun Aus datum?

Wir verwenden Rails 4.1 und die Nebel (~> 1.28.0) und Right_aws (~> 3.1.0) Edelsteine ​​für AWS Zugang und wir sind auf Heroku. Unsere App bietet unseren Nutzern in unserer Benutzeroberfläche signierte HTTPS-Links zu S3-Ressourcen.

Ist dies nur ein Client (Browser) Problem oder etwas, das wir besser verstehen und testen/beheben müssen?

Answer 1

fog verwendet excon für seinen HTTP (s) -Transport. excon ist ein Low-Level-pure-ruby-HTTP-Client, der auf die Ruby OpenSSL-Bindungen angewiesen ist. Obwohl es möglich ist, explizit eine ssl-Version zu verwenden, tut excon das nicht, was meines Wissens nach bedeuten sollte, dass es mit dem Server verhandelt, um auszuwählen, was zu verwenden ist (wenn also der Server nicht nach SSLv3 fragt, sollte es dies tun) kooperieren).

Ich glaube, dass sollte bedeuten, dass hier keine Aktion erforderlich wäre, aber die Besonderheiten von all dem unterscheiden sich ein wenig zwischen Ruby und OpenSSL-Versionen (nicht zu erwähnen, dass es schwierig ist, die Besonderheiten dieser Bindungen zu verstehen)), so ist es schwer zu sagen. excon unterstützt ein ssl_version-Argument, das verwendet werden kann, um eine bestimmte Version zu erzwingen, wenn es ein Problem sein sollte (dies ist keine gute allgemeine Wahl, da die Verhandlung nicht erlaubt ist und die Besonderheiten zwischen Ruby-Versionen variieren).

Hoffe, dass hilft.

Answer 2

Es ist ein clientseitiges Problem vollständig, wenn das Protokoll, das der Client (z. B. der Browser) verwendet, um Anforderungen über HTTPS ausgibt, SSLv3 ist, als der SSL-Handshake nicht erfolgreich ist und diese Anforderungen fehlschlagen. Es ist also der Client, der SSLv3 deaktivieren muss.

Die Aktion von AWS ist eine Folge der im letzten Jahr aufgedeckten POODLE-Schwachstelle und seither wurden auch alle AWS CloudFront-Distributionen, die den Domänennamen * .cloudfront.net verwenden, mit der eingestellten SSLv3-Unterstützung aktualisiert. Jetzt bewegt sich AWS weiter zu S3, um das Gleiche zu tun.

Answer 3

Termin wurde verschoben:

Based on the feedback received we are extending the deadline for discontinuing support of SSLv3 for securing connections to S3 buckets to 12:00 AM PDT May 20, 2015.

Answer 4

Mai Update 7 2015 11.26 IST

In carrierwave initializer, die Dinge, wie folgend,

CarrierWave.configure do |config| 
    config.fog_credentials = { 
     :provider    => 'AWS',  # required 
     :aws_access_key_id  => Settings.carrier_wave.amazon_s3.access_key,  # required 
     :aws_secret_access_key => Settings.carrier_wave.amazon_s3.secret_key,  # required 
     :region     => 'external-1' # optional, defaults to 'us-east-1' 
    } 
    config.fog_directory = Settings.carrier_wave.amazon_s3.bucket     # required 
    #config.fog_host  = 'http://aws.amazon.com/s3/'   # optional, defaults to nil 
    config.fog_public  = false         # optional, defaults to true 
    config.fog_authenticated_url_expiration = 600 
    config.fog_attributes = {ssl_version: :TLSv1_2} #{'Cache-Control'=>'max-age=315576000'} # optional, defaults to {} 
end 

Das funktionierte für mich und werfen Sie einen Blick auf das Wireshark Trace Log.

1577 22.611358000 192.168.0.113 8.8.8.8 DNS 87 Standard query 0xffd8 A s3-external-1.amazonaws.com 
1578 22.611398000 192.168.0.113 8.8.8.8 DNS 87 Standard query 0xbf2f AAAA s3-external-1.amazonaws.com 
1580 22.731084000 8.8.8.8 192.168.0.113 DNS 103 Standard query response 0xffd8 A 54.231.1.234 
1586 22.849595000 54.231.10.34 192.168.0.113 TLSv1.2 107 Encrypted Alert 

1594 23.012866000 192.168.0.113 54.231.1.234 TLSv1.2 347 Client Hello 
1607 23.310950000 192.168.0.113 54.231.1.234 TLSv1.2 204 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 
1608 23.578966000 54.231.1.234 192.168.0.113 TLSv1.2 129 Change Cipher Spec, Encrypted Handshake Message 
1609 23.579480000 192.168.0.113 54.231.1.234 TLSv1.2 427 Application Data 
1610 23.868725000 54.231.1.234 192.168.0.113 TLSv1.2 299 Application Data 

---

-Update 6. Mai 2015, 6-53 Uhr IST

Ok, nach Anhörung des Excon Juwel aktualisieren, dann sind wir in der Lage, das TLSv1.2 Protokoll zwischen unserem Server und S3-Server zu sehen.

bundle update excon

Wireshark Trace-Protokoll Aussagen,

29 1.989230000 192.168.0.115 54.231.32.0 SSL 336 Client Hello 
34 2.215461000 54.231.32.0 192.168.0.115 TLSv1.2 1494 Server Hello 
40 2.219301000 54.231.32.0 192.168.0.115 TLSv1.2 471 Certificate 
42 2.222127000 192.168.0.115 54.231.32.0 TLSv1.2 204 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 

---

UPDATE 6. Mai 2015, 29.04 Uhr IST

Nach der Aktualisierung der Hosts-Datei ist nach dem Wireshark-Ablaufprotokoll.

14 2.012094000 192.168.0.115 54.231.32.0 SSLv3 192 Client Hello 
17 2.242423000 54.231.32.0 192.168.0.115 SSLv3 61 Alert (Level: Fatal, Description: Handshake Failure) 

---

Bitte beachten Sie die oben wireshark Anfrage zu erfassen, wenn ich eine Datei von meiner lokalen Entwicklungsschiene auf S3 hochladen. Wie es zeigt, verwendet Amazon Server beim ersten Handshake SSLv3 und so sendet mein Rails Server alle zukünftigen Anfragen mit SSLv3.

Nun ist die Frage, wie kann ich die Bucket-Einstellungen ändern, so dass es den Prozess nur mit TLS akzeptieren/initiieren würde? Ich habe amazon Einstellungen eingecheckt, es gibt nichts dergleichen.

Ich habe bereits mein nginx geändert, um TLS zu verwenden, aber ich denke, dass das nicht benötigt wird, weil Rails mit S3 im Hintergrund mit Excon sprechen wird, wie im obigen Kommentar erwähnt.

Also, bitte schlagen Sie vor, was der beste Weg sein könnte, dies vor dem 20. Mai zu testen, um sicherzustellen, dass es an diesem Tag nicht bricht.

Jede Hilfe wäre großartig.

Nur zur Information - Mein Bucket Name ist wie xyz.abc.com, also nein - im Namen.

Answer 5

offiziellen FAQs AWS https://forums.aws.amazon.com/thread.jspa?threadID=179904&tstart=0

54.231.32.0 s3.amazonaws.com 
54.231.32.1 <bucket name>.s3.amazonaws.com 
54.231.32.3 <bucket name>.s3-external-1.amazonaws.com 

Konfigurieren des oben in Ihrem /etc/hosts, ersetzen <bucket name> mit Ihrem Eimer Namen.

HINWEIS: Wenn Sie mit einem nicht us-east-1 Bucket arbeiten, können Sie Redirect- und Fehlerreaktionen erhalten. Dies hat mehr mit ihrer Adhoc-Infrastruktur zu tun, als dies zu testen. Also ignorier das.

Erstellen Sie einen "Standard-US-Bucket" und testen Sie stattdessen mit diesem. Denken Sie daran, Ihre App zu konfigurieren, um s3 Region external-1

FWIW, meine App mit paperclip (4.2.0) auf ruby 2.1.4 funktioniert gut.

Answer 6

konnte ich TLS zwingen, die folgende Einstellung in meinem Nebel config:

connection_options: {ssl_version: TLSv1_2}

Um zu testen, aktualisieren Sie Ihre Host-Datei (Anweisungen von AWS):

54.231.32.0 s3.amazonaws.com 
54.231.32.1 bucket.s3.amazonaws.com #replace bucket with your bucket name 
54.231.32.3 bucket.s3-external-1.amazonaws.com #replace bucket with your bucket name 

Ich konnte erfolgreich verbinden. Wenn Sie die Einstellung zu: SSLv3 ändern, erhalten Sie einen Fehler. Viel Glück!