ruby-on-rails - rails - nodejs s3 upload
AWS S3 Deshabilitar la compatibilidad con SSLv3 (6)
Recibimos un correo electrónico de AWS que básicamente dice ''S3 está desactivando SSLv3 Support, el acceso se interrumpirá en 15 días''. A continuación, enumeraron algunos depósitos que tenemos (uno en producción) que están ''aceptando solicitudes actualmente de clientes que especifican SSLv3''. El correo electrónico completo está aquí, y otros usuarios de AWS parecen haber recibido uno también:
https://gist.github.com/anonymous/4240c8af5208782c144c
Mi pregunta es ¿cómo probamos este escenario y qué debemos hacer para prepararnos para esta fecha límite?
Usamos Rails 4.1 y las gemas Fog (~> 1.28.0) y right_aws (~> 3.1.0) para el acceso AWS y estamos en Heroku. Nuestra aplicación proporciona enlaces HTTPS firmados a recursos S3 para nuestros usuarios de navegador en nuestra interfaz de usuario.
¿Es solo un problema del cliente (navegador) o algo que necesitamos entender mejor y probar / corregir?
Es un problema del lado del cliente por completo, si el protocolo que el cliente (por ejemplo, el navegador) utiliza para emitir solicitudes sobre https es SSLv3, entonces el slsl handshake no tendrá éxito y estas solicitudes fallarán. Entonces, es el cliente quien necesita deshabilitar SSLv3.
La acción de AWS es un seguimiento de la vulnerabilidad de POODLE descubierta el año pasado y, desde entonces, todas las distribuciones de AWS CloudFront que usan el nombre de dominio * .cloudfront.net se han actualizado con el soporte descontinuado de SSLv3. Ahora AWS se está moviendo a S3 para hacer lo mismo.
La fecha límite se ha movido:
En base a los comentarios recibidos, estamos ampliando el plazo para suspender el soporte de SSLv3 para asegurar las conexiones a los segmentos de S3 a las 12:00 a.m. PDT del 20 de mayo de 2015.
Preguntas frecuentes oficiales de 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
Configure lo anterior en su /etc/hosts , reemplazando <bucket name> con su nombre de cubo.
NOTA: cuando se utiliza con un segmento us-east-1 no sea de us-east-1 puede recibir una redirección y respuestas de error. Esto tiene más que ver con su infraestructura adhoc para probar esto que cualquier otra cosa. Entonces ignora eso.
Crea un "cubo estándar de EE. UU." Y prueba con eso. Recuerde configurar su aplicación para usar s3 region external-1
FWIW, mi aplicación que usa paperclip (4.2.0) en ruby 2.1.4 funciona bien.
Pude forzar a TLS usando la siguiente configuración en mi configuración de niebla:
connection_options: {ssl_version:: TLSv1_2}
Para probar, actualice su archivo host (instrucciones de 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
Pude conectarme exitosamente Además, si cambia la configuración a: SSLv3, obtendrá un error. ¡Buena suerte!
fog usa excon para su transporte http (s). excon es un cliente http de bajo nivel de rubí puro, que confía en los enlaces de ruby openssl para funcionar. Aunque es posible establecer explícitamente una versión ssl para usar, excon no lo hace, lo que a mi leal saber y entender significa que negocia con el servidor para elegir qué usar (por lo que si el servidor no solicita SSLv3, debería hacerlo). cooperar).
Creo que eso debería significar que no se requeriría ninguna acción aquí, pero los detalles de todo eso varían un poco en las versiones de Ruby y OpenSSL (sin mencionar que es un poco difícil introspectar / comprender los detalles de esas uniones), por lo que es difícil de decir con certeza. excon admite un argumento ssl_version, que puede usarse para forzar una versión específica si termina siendo un problema (esta no es una buena opción general porque no permite la negociación y los detalles varían entre las versiones ruby).
Espero que ayude.
Actualización 7 de mayo de 2015, 11:26 a.m. IST
En el inicializador de la onda transportadora, coloque las cosas como sigue,
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
Esto funcionó para mí, y eche un vistazo al registro de seguimiento wireshark.
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
Actualización 6 de mayo de 2015, 6-53 PM IST
Ok, después de actualizar la gema Excon, podemos ver el protocolo TLSv1.2 entre nuestro servidor y los servidores S3.
bundle update excon
Declaraciones de registro de seguimiento de Wireshark,
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
ACTUALIZACIÓN 6 de mayo de 2015, 4-29 PM IST
Después de actualizar el archivo hosts, a continuación se muestra el registro de seguimiento wireshark.
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)
Consulte la captura de solicitud de wireshark anterior, cuando cargue un archivo de mis raíles de desarrollo local en S3. Como se muestra, en el saludo inicial, el servidor de Amazon usa SSLv3 y mi servidor de rieles envía todas las solicitudes futuras con SSLv3.
Ahora, la pregunta es, ¿cómo puedo cambiar la configuración del depósito para que acepte / inicie el proceso usando solo TLS? He verificado en la configuración de Amazon, no hay nada como eso.
Ya he cambiado mi nginx para usar TLS, pero creo que no es necesario porque Rails hablará con S3 en segundo plano usando Excon como se menciona en el comentario anterior.
Por lo tanto, sugiera cuál podría ser la mejor manera de probar esto antes del 20 de mayo, para asegurarse de que no se rompa ese día.
Cualquier ayuda sería genial.
Solo para obtener información: mi nombre de depósito es como xyz.abc.com, entonces no, en el nombre.