2013-03-15 14 views
8

Sto cercando di creare un'autenticazione SSL reciproca con Heroku, dove una terza parte chiama un endpoint Heroku e la risposta da Heroku dipende da quale terza parte chiama Heroku. Ho bisogno di usare mutuo ssl in quanto le terze parti sono molto attente alla sicurezza.Ottenere informazioni sull'autenticazione SSL reciproca con Heroku

Ho una terza parte che chiama Heroku (tramite l'add-on SSL) con un certificato e sono in grado di ottenere una risposta. Quindi l'handshake mutuo SSL sembra aver funzionato.

Tuttavia, la mia domanda non è in grado di determinare quale terza parte abbia chiamato Heroku poiché non ci sono informazioni sul certificato da esaminare. Ho esaminato le intestazioni Heroku per vedere se ci sono ulteriori informazioni fornite dall'aggiunta SSL, ma non ho trovato nulla.

C'è un modo per ottenere informazioni sul certificato dall'handshake reciproco tramite qualsiasi altro metodo per Heroku?

+0

Ho contattato Heroku. Mi hanno fatto sapere che questo semplicemente non è possibile. Forse qualcuno ha ancora qualche soluzione, ma immagino che sia improbabile. –

+0

Heroku mi ha informato che se c'è una soluzione funzionante con ELB, probabilmente possono farlo funzionare anche. –

risposta

4

SSL Heroku è implementato utilizzando Amazon Elastic Load Balancers (ELB), che fornisce la terminazione SSL con il certificato SSL davanti alla rete di routing di Heroku.

Poiché il protocollo SSL viene interrotto e i dettagli della negoziazione non vengono inoltrati, non è possibile ottenere informazioni sul certificato dall'handshake SSL reciproco.

Tuttavia, se l'obiettivo è utilizzare l'autenticazione basata su certificato per autenticare il client HTTP, è possibile crearlo a livello di applicazione.

Declinazione di responsabilità: Non sono un crittografo e si consiglia di consultarne uno prima di creare un meccanismo di autenticazione crittografico.

Il certificato del client può essere utilizzato per firmare un token che è possibile verificare. Di solito, un token di autenticazione include alcuni user_id, un timestamp e un grande nonce. È possibile passare questo tramite un'intestazione HTTP o un parametro di query HTTP con la richiesta, fornendo l'autenticazione a livello di app, non a livello di SSL.

Per esempio:

# Half-ass ruby-ish pseudocode 
def generate_auth_token(user_id, cert_private_key) 
    auth_payload = "#{user_id}::#{timestamp}::#{nonce}" 
    token = sign(cert_private_key, auth_payload) 
end 

def authenticate(cert_public_key, token) 
    user_id = extract_user_id(token) 
    valid_token = validate_signature(token, cert_public_key) 

    valid_token ? user_id : nil 
end 

def validate_signature(cert_public_key, token) 
    # False if signature isn't valid cryptographically based on key 
    # False if timestamp isn't recent 
    # False if format isn't legit 
    # Otherwise true 
end 
+0

Grazie per la risposta. È fondamentalmente ciò che dice anche Heroku. Mentre il tuo approccio funziona bene con il servizio per la comunicazione di servizio, non funzionerà bene per i browser. Attualmente utilizziamo l'autenticazione a due fattori tramite ROTP e stiamo esaminando l'integrazione yubikey. –

+0

Ho fatto qualche ricerca in più e una opzione con ELB sarebbe quella di indirizzare il traffico SSL verso un pool di load balancer SSL che controlli, che potrebbero implementare la terminazione SSL e la convalida del cert sul lato client. Ciò elimina gran parte del valore ELB, imho, ma consentirebbe un bilanciamento del carico pubblico di fronte a un livello SSL, di fronte a un livello di applicazione. – Winfield

Problemi correlati