HTTPS, SSL & BEAST attack - ρύθμιση apache

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

HTTPS, SSL & BEAST attack - ρύθμιση apache

Savvas Radevic
Έχει κάποιος εμπειρία με θέματα ασφάλειας, SSL & Beast attack;

Συγκεκριμένα, ποια είναι η πιο ασφαλής ρύθμιση του apache για ssl;
Έχω απενεργοποιήσει το TLSv1 και το SSLv2, πρέπει να κάνω και κάτι άλλο; :problem:
Επίσης, διάβασα ότι το RC4 δεν είναι ασφαλές πλέον. Αληθεύει;
Μήπως κάποιος ξέρει ποια "cipher suites" να χρησιμοποιήσω στο "SSLCipherSuite";

Το ssl είναι class 1 από το http://www.startssl.com αν έχει σημασία.

Φαίνεται πως αυτή η ρύθμιση δουλεύει:

   SSLEngine on

   SSLCompression off  # disallow for this vhost
   SSLHonorCipherOrder On
   SSLProtocol all -SSLv2 -TLSv1
   SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM

   SSLCertificateFile /etc/ssl/ssl.crt
   SSLCertificateKeyFile /etc/ssl/ssl.key
   SSLCertificateChainFile /etc/ssl/sub.class1.server.ca.pem
   SSLCACertificateFile /etc/ssl/ca.pem



Μήπως γνωρίζει κάποιος αν είναι εντάξει αυτή η ρύθμιση; Και αν υποστηρίζεται από τους κοινούς browsers (chrome/ium, IE, mozilla firefox, opera);


Μπορείτε να ελέγξετε το ssl του δικού σας server με το testsslserver.jar: http://www.bolet.org/TestSSLServer/

wget http://www.bolet.org/TestSSLServer/TestSSLServer.jar
java -jar TestSSLServer.jar oserversas.gr 443


Reply | Threaded
Open this post in threaded view
|

Re: HTTPS, SSL & BEAST attack - ρύθμιση apache

Simos Xenitellis-4

2013/7/11 Savvas Radevic <[hidden email]>
Έχει κάποιος εμπειρία με θέματα ασφάλειας, SSL & Beast attack;


Το BEAST είναι ένα από τα ζητήματα, και υπάρχουν και άλλα όπως το CRIME.
 
Συγκεκριμένα, ποια είναι η πιο ασφαλής ρύθμιση του apache για ssl;

Γενικά πιστεύω ότι η σελίδα http://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ περιγράφει επιγραμματικά την όλη κατάσταση. Για Ubuntu και ιδίως το 12.04, έχουν γίνει backport στον Apache κάποιες διορθώσεις που έγιναν στο Apache 2.4.
 
Έχω απενεργοποιήσει το TLSv1 και το SSLv2, πρέπει να κάνω και κάτι άλλο; :problem:

Αυτό το SSLv2 είναι από το 1996 και δεν είναι σε πρακτική χρήση πια, οπότε μια χαρά.

Το TLSv1 ξεκίνησε το 1999 και το 2006 βγήκε το TLSv1.1 (και πιο πρόσφατα το TLSv1.2).
Μέχρι και το 2011 περίπου, οι δημοφιλείς περιηγητές όπως Chrome δεν υποστήριζαν TLSv1.1 ή νεότερο. Οπότε, αν υπάρχει πελάτης που έχει διατηρήσει με κάποιο τρόπο μια παλιά έκδοση περιηγητή (ή κανένα πραγματικά παλιό Explorer 6), τότε χρειάζεσαι να υποστηρίζεις το TLSv1.
 
Επίσης, διάβασα ότι το RC4 δεν είναι ασφαλές πλέον. Αληθεύει;

Γενικά στην ασφάλεια υπάρχουν περιπτώσεις όπου το αν κάτι είναι ασφαλές ή όχι, έχει πολλές διαβαθμίσεις.
Πράγματι, από πλευράς κρυπτογραφίας (ακαδημαϊκά) το RC4 δεν είναι ασφαλές, ωστόσο από πλευρά πρακτικής εκμετάλλευσης κάποιας αδυναμίας, το πρόβλημα δεν είναι τόσο κρίσιμο όπως για παράδειγμα θα ήταν κρίσιμο να βάλεις WEP σε ασύρματο δίκτυο.
 
Μήπως κάποιος ξέρει ποια "cipher suites" να χρησιμοποιήσω στο "SSLCipherSuite";

Το ssl είναι class 1 από το http://www.startssl.com αν έχει σημασία.


Μπορείς να δεις τα χαρακτηριστικά του πιστοποιητικού όπως αν χρησιμοποιεί SHA265 ή SHA384 κτλ, και να κανονίσεις κατάλληλα παρακάτω στο ciphersuite.
 
Φαίνεται πως αυτή η ρύθμιση δουλεύει:

   SSLEngine on

   SSLCompression off  # disallow for this vhost


Οκ για αντιμετώπιση του CRIME.
 
   SSLHonorCipherOrder On
   SSLProtocol all -SSLv2 -TLSv1

Με απενεργοποίηση του TLSv1 μπορεί να συναντήσεις πελάτες που δε θα μπορούν να συνδεθούν, είτε διότι έχουν παλιές εκδόσεις περιηγητών Chrome, Firefox, είτε επειδή κόλλησαν στον IE 6.0/7.0, είτε προσπαθούν να συνδεθούν από κάποιο παράξενο κινητό.
 
   SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM

Εδώ θα πρότεινα κάτι σαν
SSLCipherSuite AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

Αυτό το GCM είναι καλό, και στη δική σου εκδοχή αναφέρεις να μη χρησιμοποιηθεί το AESGCM
(που δεν γνωρίζω πως σχετίζεται με AES128-GCM-SHA256 και το
AES256-SHA256 που δηλώνεις εσύ.).


   SSLCertificateFile /etc/ssl/ssl.crt
   SSLCertificateKeyFile /etc/ssl/ssl.key
   SSLCertificateChainFile /etc/ssl/sub.class1.server.ca.pem
   SSLCACertificateFile /etc/ssl/ca.pem



Μήπως γνωρίζει κάποιος αν είναι εντάξει αυτή η ρύθμιση; Και αν υποστηρίζεται από τους κοινούς browsers (chrome/ium, IE, mozilla firefox, opera);


Μπορείτε να ελέγξετε το ssl του δικού σας server με το testsslserver.jar: http://www.bolet.org/TestSSLServer/

wget http://www.bolet.org/TestSSLServer/TestSSLServer.jar
java -jar TestSSLServer.jar oserversas.gr 443


Έχει δοκιμή και στο https://www.ssllabs.com/ssltest/

Σίμος
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS, SSL & BEAST attack - ρύθμιση apache

Savvas Radevic
Ευχαριστώ :)

Ακόμη μια ερώτηση, τα TLSv* αντικατέστησαν τα SSLv*; Τα SSLv* είναι πιο παλιά από ιστορικής απόψεως;
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS, SSL & BEAST attack - ρύθμιση apache

Simos Xenitellis-4

On Thu, Jul 11, 2013 at 7:33 PM, Savvas Radevic <[hidden email]> wrote:

Ακόμη μια ερώτηση, τα TLSv* αντικατέστησαν τα SSLv*; Τα SSLv* είναι πιο
παλιά από ιστορικής απόψεως;

Αυτό το SSLv* είναι η ονομασία που έδωσε αρχικά η Netscape, όταν πρωτοδημιούργησε τα πρωτόκολλα.
Όταν αυτά προτυτοποιήθηκαν, τότε το SSLv3 (τελευταίο της σειράς SSLv*) μετατράπηκε σχεδόν αυτούσιο σε TLSv1 (διεθνές πρότυπο), και γιαυτό διαβάζεις για «SSL/TLS». Περνάμε σταδικά στα TLSv1, TLSv1.1 και τώρα TLSv1.2.

Κάτι που γίνεται της μόδας στο SSL/TLS είναι το Perfect Forward Secrecy (PFS), όπου επιτρέπει την ασφαλή επικοινωνία μεταξύ π.χ. περιηγητή και εξυπηρετητή ιστοσελίδων, ακόμα και στην περίπτωση που κάποια στιγμή στο μέλλον κάποιος καταφέρει να σπάσει τα πιστοποιητικά. Δηλαδή, όταν διαβάζεις τώρα το GMail σου με σύνδεση SSL/TLS στο https://mail.google.com/ και θεωρήσουμε ότι, και ο περιηγητής σου είναι ασφαλής, και το mail.google.com, τότε αν κάποιος καταγράψει τα πακέτα της κρυπτογραφημένης επικοινωνίας και θελήσει αργότερα να την αποκρυπτογραφήσει διότι έσπασε αργότερα το πιστοποιητικό του mail.google.com, δεν μπορεί. Διότι με τη χρήση PFS η κάθε επικοινωνία χρησιμοποιεί ένα προσωρινό κλειδί με τέτοιο τρόπο που αυτό δεν εμφανίζεται κατά τη μετέπειτα αποκρυπτογράφηση της επικοινωνίας.

Αυτό το PFS είναι σημαντικό ιδίως σε δικούς μας εξυπηρετητές με SSL/TLS, οπότε ακόμα και όταν εταιρίες όπως η Verisign δώσουν σε τρίτους τα κλειδιά των πιστοποιητικών, τότε η μόνη δυνατή επίθεση είναι η ενεργή (active) αντί για παθητική (καταγραφή πακέτων επικοινωνίας). Γενικά ενεργές επιθέσεις είναι πολύ σπάνιες, και υπάρχουν τρόποι να διαπιστώσεις τι γίνεται.

Για να ελέγξεις πως πάει ένας διαδικτυακός τόπος από πλευράς SSL/TLS, δοκιμάζεις την υπηρεσία της Qualis.
Έτσι, για το https://mail.google.com δες https://www.ssllabs.com/ssltest/analyze.html?d=mail.google.com&hideResults=on
Και θα δεις ότι για της Microsoft έχει ένα σωρό προβλήματα,
1. δεν υποστηρίζει TLS v1.1, TLS v1.2
2. είναι έκθετο στο BEAST

Σίμος