Η απόφαση 2015/1506/ΕΕ σύμφωνα με τον κανονισμό (ΕΕ) 910/2014 (επίσης γνωστός ως eIDAS) έχει ορίσει έναν αριθμό από προφίλ (π.χ. PAdES, XAdES κ.λπ.) για να διασφαλίσει ότι οι ηλεκτρονικές υπογραφές μπορούν να δημιουργηθούν και να επικυρωθούν οπουδήποτε στην Ευρώπη.

Όταν ένας χρήστης εκτελεί μια διαδικασία υπογραφής με τον Acrobat και προσπαθεί να επικυρώσει την υπογραφή αργότερα χρησιμοποιώντας ένα λογισμικό επικύρωσης υπογραφής όπως το DSS (Digital Signature Service) WebApp, είτε μετά τη λήξη ή την ανάκληση του πιστοποιητικού, η επικύρωση αποτυγχάνει.

Αυτό συμβαίνει επειδή η προεπιλεγμένη συμπεριφορά του Acrobat δεν είναι σύμφωνη με το προφίλ PAdES (PDF Advanced Electronic Signature). Οι προεπιλεγμένες ρυθμίσεις του δεν περιλαμβάνουν το υποχρεωτικό χαρακτηριστικό “message-digest” (και άλλα υπογεγραμμένα χαρακτηριστικά) που επιβάλλεται από την προεπιλεγμένη πολιτική επικύρωσης DSS.

Ο Acrobat προσφέρει μια διαφορετική επιλογή υπογραφής που περιέχει το χαρακτηριστικό “message-digest” και περνά με επιτυχία την επικύρωση από την εφαρμογή DSS αλλά χρειάζεται ο χρήστης να αλλάξει τις προεπιλεγμένες ρυθμίσεις της εφαρμογής.

Για να γίνει αυτό, ο χρήστης πρέπει να ανοίξει τα «Creation & Appearance Preferences» του Acrobat και να επιλέξει το CAdES-Equivalent ως Default Signing Format.

Τέλος, συνιστάται ιδιαίτερα να είναι επιλεγμένο το checkbox “Include signature’s revocation status” ώστε η υπογραφή να είναι ενεργοποιημένη κατά LTV (Long Term Validation).

Αγαπητοί συνδρομητές της HARICA,

Πρόσφατα διαπιστώσαμε ότι ορισμένα σημεία της Πολιτικής Πιστοποίησης/Δήλωση Διαδικασιών Πιστοποίησης, που σχετίζονται με την Ανάκληση Πιστοποιητικών, δεν έχουν αποσαφηνιστεί επαρκώς στους Συνδρομητές μας. Αυτό το άρθρο επιχειρεί να περιγράψει ορισμένες «καλές πρακτικές» για Συνδρομητές και κάποιες, προς αποφυγή, προκειμένου να βελτιωθεί η συνολική ασφάλεια της χρήσης «Δημόσιων-Έμπιστων» Ψηφιακών Πιστοποιητικών προς όφελος των Βασιζόμενων Μερών (Relying Parties), διεθνώς.

Βάσει της παραγράφου 4.9.1 Συνθήκες για ανάκληση της Πολιτικής Πιστοποίησης/Δήλωσης Διαδικασιών Πιστοποίησης HARICA, από τη στιγμή που γίνει αντιληπτό ή υπάρξει ενημέρωση για πρόβλημα σε Πιστοποιητικό, ο Συνδρομητής πρέπει να ενημερωθεί άμεσα. Η HARICA πρέπει, υπό συγκεκριμένες συνθήκες, να ανακαλέσει οποιοδήποτε Πιστοποιητικό Συνδρομητή μέσα σε είκοσι τέσσερις (24) ώρες ή σε ένα διάστημα πέντε (5) ημερών, ανάλογα με το είδος του πιστοποιητικού (TLS, S/MIME, eSignature, κ.α.) και μέγεθος της απειλής. Για παράδειγμα, Πιστοποιητικά με λάθη σε πεδία στο subject του Πιστοποιητικού, πρέπει να ανακληθούν μέσα σε διάστημα πέντε (5) ημερών αλλά για περιπτώσεις που το Ιδιωτικό Κλειδί του Πιστοποιητικού υπέστη παραβίαση, η ανάκλησή τους θα γίνει μέσα σε είκοσι τέσσερις (24) ώρες. Επίσης, υπό συγκεκριμένες συνθήκες, η HARICA πρέπει να ανακαλέσει οποιαδήποτε Αρχή Έκδοσης (Πιστοποιητικό Ενδιάμεσης Αρχής Πιστοποίησης), μέσα σε διάστημα επτά (7) ημερών για λόγους που περιγράφονται στην Πολιτική Πιστοποίησης HARICA. Ένα μέρος των παραπάνω απαιτήσεων ορίζονται μέσω των CA/Browser Forum Baseline Requirements, και όλες οι Αρχές Πιστοποίησης που εκδίδουν «Δημόσια-Έμπιστα» TLS Πιστοποιητικά πρέπει να συμμορφώνονται με αυτούς τους κανόνες για τα Πιστοποιητικά που περιγράφονται σε αυτό το πρότυπο.

Έχοντας ως βάση τα παραπάνω, ΟΛΟΙ οι συνδρομητές που κατέχουν «Δημόσια-Έμπιστα» Ψηφιακά Πιστοποιητικά HARICA, θα πρέπει να είναι προετοιμασμένοι να ΔΡΑΣΟΥΝ με άμεσο και ευέλικτο τρόπο, προκειμένου να τα αντικαταστήσουν εντός των παραπάνω χρονικών πλαισίων, εφόσον κριθεί απαραίτητο.

Σύμφωνα με τους ισχύοντες κανονισμούς, δεν υπάρχει απαίτηση από τους Συνδρομητές να ενημερώνουν ή να εξηγούν στη HARICA λεπτομερώς πώς σκοπεύουν να χρησιμοποιήσουν τα Πιστοποιητικά τους για να τα αξιοποιήσουν Βασιζόμενα Μέρη. Ωστόσο, οι Συνδρομητές πρέπει να μην ξεχνούν τις απαιτήσεις ανάκλησης που έχουν συμφωνήσει μέσω της Σύμβασης Συνδρομητή και Όροι Χρήσης Υπηρεσιών HARICA, και να προσαρμόζουν τις υλοποιήσεις τους με τέτοιο τρόπο, ώστε τα Πιστοποιητικά τους να μπορούν να αντικατασταθούν εγκαίρως εντός των συγκεκριμένων χρονικών πλαισίων, εφόσον απαιτηθεί.

Υλοποιήσεις που θεωρούνται προβληματικές

Η HARICA επικοινώνησε με έναν αριθμό συνδρομητών και οργανισμών που ανέπτυξαν λύσεις με βάση τα πιστοποιητικά της και κατέληξε σε κάποια χρήσιμα συμπεράσματα. Αν και δεν είναι πρόθεσή μας να επικρίνουμε ή να σχολιάσουμε τις αποφάσεις σχεδιασμού αυτών των περιπτώσεων χρήσης, είναι προφανές ότι οι προθέσεις των Συνδρομητών ήταν να βελτιώσουν την ασφάλεια (και με μία έννοια αυτό επιτεύχθηκε περιορίζοντας τον αριθμό των «επιτρεπόμενων» πιστοποιητικών) αλλά ταυτόχρονα, υπήρξαν ακούσιες συνέπειες, για παράδειγμα η δυσκολία αντικατάστασης πιστοποιητικών και έγκαιρης προσαρμογής σε αλλαγές πολιτικής της Αρχής Πιστοποίησης.

Οι λύσεις που βασίζονται «ρητά» σε πληροφορίες που περιλαμβάνονται σε Αρχές Έκδοσης (Πιστοποιητικά Ενδιάμεσης Αρχής Πιστοποίησης), είναι ένας από τους συνηθισμένους λόγους που προκαλούν δυσκολία στους συνδρομητές να αντικαταστήσουν τα πιστοποιητικά τους. Αυτή η πρακτική είναι γνωστή ως «certificate pinning». Η διαδικασία με την οποία μια εφαρμογή “αναμένει” πιστοποιητικά ελέγχου ταυτότητας (Client ή Server) από συγκεκριμένη Αρχή Έκδοσης, θεωρείται προβληματική. Η HARICA και άλλοι Πάροχοι Υπηρεσιών Εμπιστοσύνης έχουν την ελευθερία να εκδίδουν νέες Αρχές Έκδοσης που θα τις χρησιμοποιούν για την έκδοση Πιστοποιητικών Συνδρομητών, χωρίς προηγούμενη ειδοποίηση ή επικοινωνία με τους συνδρομητές ή τα Βασιζόμενα Μέρη (Relying Parties). Οι εφαρμογές και οι λύσεις που χρησιμοποιούν τη μέθοδο «certificate pinning » σε συγκεκριμένες Αρχές Έκδοσης, ενδέχεται να παρουσιάσουν πρόβλημα και πιθανότατα θα πρέπει να ενημερωθούν χειροκίνητα σε ενδεχόμενη αλλαγή δημιουργώντας πρόβλημα στους διαχειριστές. Προτείνουμε οι υλοποιήσεις που βασίζονται στα περιεχόμενα των Πιστοποιητιών να χρησιμοποιούν πληροφορίες από τα πεδία του subject Distinguished Name του τελικού Πιστοποιητικού για τον έλεγχο ταυτότητας.

Ακολουθεί μια λίστα εφαρμογών/υλοποιήσεων, όπου αναφέρθηκε ότι χρησιμοποιήθηκε «certificate pinning»:

• έλεγχος ταυτότητας χρηστών για υπηρεσίες VPN
• έλεγχος ταυτότητας χρηστών σε υπηρεσίες Web
• σε εφαρμογές Android
• επικύρωση ψηφιακών υπογραφών συγκεκριμένων οργανισμών

Υπάρχουν επίσης υλοποιήσεις που βασίζονται σε Ψηφιακά Πιστοποιητικά για έλεγχο ταυτότητας και υπογραφές, κυρίως για επικοινωνία μεταξύ διακομιστών. Η πιστοποίηση μέσω SAML2 είναι πολύ δημοφιλής ειδικά στον Ακαδημαϊκό και Ερευνητικό χώρο (eduGAIN, InCommon Federation), όπου οι Identity Providers και οι Service Providers χρησιμοποιούν πιστοποιητικά για να υπογράψουν τα metadata και SAML2 assertions. Οι διαχειριστές τέτοιων υπηρεσιών πρέπει να γνωρίζουν ότι αυτά τα πιστοποιητικά δεν χρειάζεται να είναι «Δημόσια-Έμπιστα» και προτείνεται η χρήση self-signed πιστοποιητικών ή η χρήση ιδιωτικής Υποδομή Δημοσίου Κλειδιού.

Προετοιμαστείτε για ταχεία αντικατάσταση πιστοποιητικών

Υπάρχουν διάφοροι λόγοι για τους οποίους οι Συνδρομητές «Δημόσιων-Έμπιστων» Πιστοποιητικών πρέπει να είναι έτοιμοι για γρήγορη αντικατάστασή τους. Ανεξάρτητα από τις περιπτώσεις χρήσης, υπάρχουν πάντα κίνδυνοι στην ίδια την τεχνολογία που χρησιμοποιείται στα Ψηφιακά Πιστοποιητικά/Ηλεκτρονικές Υπογραφές. Επίσης, οι απαιτήσεις σε πολιτικές αλλάζουν από καιρό σε καιρό. Για παράδειγμα, ορισμένες υπάρχουσες μέθοδοι για Domain και Identity validation, ενδέχεται να απαγορευθούν ή να καταργηθούν επειδή, βάσει νέων στοιχείων, να χαρακτηριστούν μη-ασφαλείς. Εάν αυτές οι μέθοδοι χρησιμοποιήθηκαν για την έκδοση πιστοποιητικών, είναι πιθανό να πρέπει να βρεθούν τα πιστοποιητικά που χρησιμοποίησαν τις μη-ασφαλείς μεθόδους και να πρέπει να ανακληθούν. Η ευελιξία λόγω αλλαγών σε Πολιτικές ή σε τεχνολογικές εξελίξεις σε θέματα αλγορίθμων κρυπτογράφησης, είναι μερικοί από τους λόγους που απαιτούν Παρόχους Υπηρεσιών Εμπιστοσύνης -όπως η HARICA-, Συνδρομητές και Βασιζόμενα Μέρη (Relying Parties) να είναι σε θέση να προσαρμοστούν γρήγορα στις αλλαγές.

Η HARICA προτείνει τις ακόλουθες καλές πρακτικές στους συνδρομητές πιστοποιητικών TLS:

• Οι συνδρομητές μπορούν να χρησιμοποιούν υλοποιήσεις που βασίζονται στο πρωτόκολλο ACME για αυτόματη έκδοση/ανανέωση πιστοποιητικών. Η HARICA υποστηρίζει ACME (πιλοτική υπηρεσία) σε επιλεγμένους Οργανισμούς για αυτόματη έκδοση πιστοποιητικών TLS. Αυτή η λύση σχεδιάζεται να προσφερθεί σύντομα σε όλους τους Συνδρομητές.
• Οι συνδρομητές που χρησιμοποιούν πιστοποιητικά TLS σε υπηρεσίες/συσκευές που εφαρμόζουν παλιό λογισμικό/πρωτόκολλα που έχουν καταργηθεί (π.χ. TLS 1.0 ή 1.1 για λογισμικό IP κάμερας), συνιστάται να χρησιμοποιούν διακομιστές μεσολάβησης (proxies) που παρέχουν ασφαλή σύνδεση TLS, χρησιμοποιώντας τις τελευταίες εκδόσεις πρωτοκόλλων, που υποστηρίζουν επίσης ACME.

Η HARICA είναι έτοιμη να ανταποκριθεί σε καταστάσεις που απαιτείται γρήγορη αντικατάσταση μη-TLS πιστοποιητικών:

• Για Πιστοποιητικά S/MIME, «Προηγμένης» Ηλεκτρονικής Υπογραφής/Σφραγίδας και Υπογραφής Κώδικα (όχι EV), η HARICA μπορεί να εκδώσει ένα νέο πιστοποιητικό, χρησιμοποιώντας μερικές ή όλες τις πληροφορίες που υποβλήθηκαν για ένα υπάρχον πιστοποιητικό και χρησιμοποιώντας ένα νέο Ζεύγος Κλειδιών.
• Για Πιστοποιητικά Υπογραφής Κώδικα (EV), «Εγκεκριμένης» Ηλεκτρονικής Υπογραφής/Σφραγίδας και σε περίπτωση που η κρυπτοσυσκευή ή το ιδιωτικό κλειδί ΔΕΝ έχει παραβιαστεί, η HARICA μπορεί:
  • Να χρησιμοποιήσει το ίδιο Ζεύγος Κλειδιών και να εκδώσει ένα εντελώς νέο πιστοποιητικό, χρησιμοποιώντας μερικές ή όλες τις πληροφορίες που υποβλήθηκαν για ένα υπάρχον πιστοποιητικό ή
  • να δημιουργήσει ένα νέο Ζεύγος Κλειδιών και να εκδώσει ξανά το ίδιο πιστοποιητικό χρησιμοποιώντας το νέο κλειδί ή
  • να χρησιμοποιήσει ένα υπάρχον Ζεύγος Κλειδιών, που δημιουργήθηκε επιπλέον του αρχικού στην κρυπτοσυσκευή, και να εκδώσει ένα νέο πιστοποιητικό.
• Για συνδρομητές πιστοποιητικού εξ αποστάσεως ηλεκτρονικής υπογραφής/σφραγίδας, η HARICA μπορεί να χρησιμοποιήσει ένα νέο Ζεύγος Κλειδιών και να εκδώσει ένα νέο πιστοποιητικό, χρησιμοποιώντας μερικές ή όλες τις πληροφορίες που υποβλήθηκαν για ένα υπάρχον πιστοποιητικό.

Σχετικά άρθρα

• https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
• https://www.nginx.com/blog/nginx-ssl/
• https://www.haproxy.com/blog/haproxy-ssl-termination/
• https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222
• https://technical.edugain.org/