Comment faire une demande https avec certificat incorrect?

Dire que je veux obtenir https://golang.org par programmation. Actuellement golang.org (ssl) a un mauvais certificat qui est délivré à *.appspot.com Donc, quand je lance ceci:

package main

import (
    "log"
    "net/http"
)

func main() {
    _, err := http.Get("https://golang.org/")
    if err != nil {
        log.Fatal(err)
    }
}

- Je obtenir (comme je m'y attendais)

Get https://golang.org/: certificate is valid for *.appspot.com, *.*.appspot.com, appspot.com, not golang.org

Maintenant, je veux faire confiance à ce certificat de moi-même (imaginez un certificat auto-émis où je peux valider les empreintes digitales, etc.): comment puis-je faire une demande et de valider/confiance au certificat?

J'ai probablement besoin d'utiliser openssl pour télécharger le certificat, le charger dans mon fichier et de le remplir tls.Config struct !?

  • ce n'est pas un "mauvais" certificat " c'est un certificat avec un autre CN. InsecureSkipVerify n'est pas une utilisation légitime ici. Vous devez définir ServerName dans la tls.Config correspond à ce que vous essayez de vous connecter. Cette StackOverflow post est à l'origine de ce gros trou de sécurité dans le Go du code pour se répandre partout. InsecureSkipVerify ne pas vérifier le certificat du TOUT. Ce que vous voulez est de vérifier que le certificat a été valablement signés par une entité de confiance, même si le CN ne correspond pas au nom d'hôte. Les Tunnels et les NATS peut légitimement à l'origine de ce décalage.
InformationsquelleAutor topskip | 2012-08-25
  1. 218

    De sécurité remarque: la Désactivation des contrôles de sécurité est dangereuse et doit être évitée

    Vous pouvez désactiver les contrôles de sécurité à l'échelle mondiale pour toutes les demandes du client par défaut:

    package main

import (
    "fmt"
    "net/http"
    "crypto/tls"
)

func main() {
    http.DefaultTransport.(*http.Transport).TLSClientConfig = &tls.Config{InsecureSkipVerify: true}
    _, err := http.Get("https://golang.org/")
    if err != nil {
        fmt.Println(err)
    }
}

    Vous pouvez désactiver le contrôle de sécurité pour un client:

    package main

import (
    "fmt"
    "net/http"
    "crypto/tls"
)

func main() {
    tr := &http.Transport{
        TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
    }
    client := &http.Client{Transport: tr}
    _, err := client.Get("https://golang.org/")
    if err != nil {
        fmt.Println(err)
    }
}
    • Je me demande où mettre un certificat de confiance, de sorte que la connexion peut être utilisée sans InsecureSkipVerify: true. Est-ce possible?
    • NameToCertificate peut aider, voir la tls.Config de la documentation : golang.org/pkg/crypto/tls/#Config
    • Lors de l'utilisation de ce moyen de désactiver la vérification, il a travaillé pour le cas où le certificat a expiré, mais pas pour les cas les certificats auto-signés. Ne InsecureSkipVerify vraiment ignorer la vérification de la sécurité?
    • Voici un exemple pour l'ajout de certificat d'autorité de certification piscines: golang.org/pkg/crypto/tls/#example_Dial Vous pouvez l'utiliser dans un client HTTP en tant que bien.
    • Fonctionne pour les certificats auto-signés aussi bien pour moi
    • Beaucoup de gens finissent par ici pour essayer de désactiver le nom d'hôte de contrôle (pas complètement désactiver les vérifications de certificats). C'est la mauvaise réponse. Allez vous demande de configurer le nom du serveur dans le tls config pour correspondre à la CN de l'hôte auquel vous vous connectez, si ce n'est pas le nom dns de vous connecter avec. InsecureSkipVerify n'est pas plus sécurisé qu'un bon vieil telnet sur le port. Il n'y a PAS d'authentification avec ce paramètre. L'utilisateur ServerName au lieu!
    • notez qu'il y a RootCAs et ClientCAs. Si vous avez un client cert, puis ClientCAs spécifie ce qu'il a signé le client cert. RootCAs spécifie quel signé le serveur cert. ServerName est le CN prévu lorsque vous vous connectez à un autre ordinateur. Par défaut, il devrait être le nom d'hôte que vous vous y connectez, comme: http://www.foobank.com:8443 attend CN http://www.foobank.com.
    • Mais si c'est parfaitement légitime cert où le CN est partagée entre les machines, comme "authorizationService", puis définissez ServerName pour "authorizationService" pour correspondre à la CN plutôt que le nom d'hôte ou l'adresse IP que vous utilisez pour vous connecter à elle. Cela arrive souvent avec des groupes qui ont des adresses ip dynamiques et les noms d'Hôtes. InsecureSkipVerify peut être une catastrophe quand vous obtenez les noms d'hôtes de choses comme accessible zookeeper serveurs.
    • Méfiez-vous: Un transport créé comme qui utilise zéro des valeurs pour la plupart de ses champs et donc perd tous les paramètres par défaut. Comme la réponse ci-dessous le suggère, vous pouvez les copier sur. Nous avons eu une bonne dose de fun à comprendre pourquoi nous manquons de descripteurs de fichiers, parce que nous avons perdu la Dialer.Timeout.
    • J'ai utilisé stackoverflow.com/questions/31535569/... pour modifier la réponse maintenant, http.DefaultTransport.(*http.De Transport).TLSClientConfig = &tls.Config{InsecureSkipVerify: true} a cessé de fonctionner. Aucune idée pourquoi?

    InformationsquelleAutor cyberdelia
  2. 12

    Voici un moyen de le faire sans perdre les paramètres par défaut de la DefaultTransport, et sans avoir besoin de la faux de la demande par l'utilisateur commentaire.

    defaultTransport := http.DefaultTransport.(*http.Transport)

//Create new Transport that ignores self-signed SSL
httpClientWithSelfSignedTLS := &http.Transport{
  Proxy:                 defaultTransport.Proxy,
  DialContext:           defaultTransport.DialContext,
  MaxIdleConns:          defaultTransport.MaxIdleConns,
  IdleConnTimeout:       defaultTransport.IdleConnTimeout,
  ExpectContinueTimeout: defaultTransport.ExpectContinueTimeout,
  TLSHandshakeTimeout:   defaultTransport.TLSHandshakeTimeout,
  TLSClientConfig:       &tls.Config{InsecureSkipVerify: true},
}

    Avertissement: Pour les tests et à des fins de développement uniquement. Autre chose, procéder à vos propres risques!!!

    • Voir les commentaires ci-dessus. TOUS ces éléments sont des faux!
    InformationsquelleAutor Jonathan Lin
  3. 11

    Toutes ces réponses sont fausses! Ne pas utiliser InsecureSkipVerify de traiter avec un CN qui ne correspond pas au nom d'hôte. L'Aller développeurs imprudemment ont insisté sur pas la désactivation de nom d'hôte de contrôle (qui a des utilisations légitimes - les tunnels, les nats, de cluster partagé certs, etc...), et aussi d'avoir quelque chose qui ressemble, mais en fait complètement ignore la vérification du certificat. Vous devez savoir que le certificat est valide et signé par un cert en qui vous avez confiance. Mais dans les scénarios courants, vous savez que le CN ne corresponde pas au nom d'hôte de vous connecter avec. Pour ceux qui, ensemble ServerName sur tls.Config. Si tls.Config.ServerName == remoteServerCN, puis le certificat de vérification de réussir. C'est ce que vous voulez. InsecureSkipVerify signifie qu'il n'y a PAS d'authentification; et il est mûr pour un Man-In-The-Middle; vaincre le but de l'utilisation de TLS.

    Il y a une utilisation légitime de InsecureSkipVerify: l'utiliser pour vous connecter à un hôte et de saisir son certificat, puis débranchez immédiatement. Si vous configurez votre code pour utiliser InsecureSkipVerify, c'est généralement parce que vous n'avez pas défini de ServerName correctement (il ne peut venir que d'un env var ou quelque chose - ne pas le ventre sur cette exigence... de le faire correctement).

    En particulier, si vous utilisez des certificats clients et comptons sur eux pour l'authentification, vous avez essentiellement un faux login qui ne fait pas de connexion, pas plus. Refuser le code qui ne InsecureSkipVerify, ou vous apprendrez quel est le problème avec elle à la dure!

    • Savez-vous un site où je peux tester cela? golang org maintenant ne renvoie pas d'erreur de plus.
    • utiliser openssl outils pour faire des certificats. vous pouvez écrire des tests unitaires pour tester cette.
    • Cette réponse est terriblement trompeuse. Si vous acceptez tout valablement signé certificat indépendamment de nom d'hôte, vous n'obtenez pas de réelle sécurité. Je peux facilement obtenir un certificat valide pour tous les domaines que je contrôle; si vous êtes juste de préciser mon nom d'hôte pour le TLS vérifier, vous perdez la validation que je suis vraiment à qui je dis que je suis. À ce point, le fait que le certificat est "légitime" n'a pas d'importance; c'est toujours mal et vous êtes à la toujours vulnérables à l'homme dans le milieu.
    • Dans une Entreprise où vous avez réellement n'avez pas confiance en aucun de l'offre commerciale des CAs (ie: si ils sont hors de NOUS, par exemple), et de la remplacer par une autorité de certification de votre Entreprise, vous avez juste besoin de valider que c'est un de vos certificats. Le nom d'hôte vérifier est pour les situations où les utilisateurs attendent le nom d'hôte de match, mais les DNS n'est pas sécurisé. Dans l'entreprise, en général, vous connecter à un cluster de machines où il n'est pas possible pour le hostname/IP de match, parce que c'est des clones d'une machine a engendré en vertu de la nouvelle IPs. Le nom dns trouve le cert, et cert est l'id, pas de nom dns.
    • l'idée est que le code client seulement fait confiance à l'autorité de certification d'entreprise. c'est beaucoup plus sécurisé que l'autorité de certification du système actuellement en usage. Dans ce cas, rien n' (Thawte, aux états-unis versign, etc)... est digne de confiance. Juste CA que nous courons. Les navigateurs Web ont d'énormes listes de confiance. Services à parler les uns aux autres le CA dans sa confiance de fichier.
    • J'ai l'habitude d'utiliser badssl.com pour ces tests.
    • merci @Rob, j'ai une configuration identique où nos services uniquement confiance à la même, seule CA et rien d'autre. Ce sont des informations essentielles et de beaucoup d'aide.

    InformationsquelleAutor Rob
  4. 7

    Si vous souhaitez utiliser les paramètres par défaut à partir de l'adresse http paquet, de sorte que vous n'avez pas besoin de créer un nouveau Transport et Client de l'objet, vous pouvez modifier d'ignorer la vérification de certificat comme ceci:

    tr := http.DefaultTransport.(*http.Transport)
tr.TLSClientConfig.InsecureSkipVerify = true
    • En faisant cela aurait pour conséquence panic: runtime error: invalid memory address or nil pointer dereference
    • Si vous n'utilisez pas la valeur par défaut http demandeur avant cela, vous devez forcer un faux demande de sorte que le transport par défaut, il est initialisé
    • ce n'est pas la désactivation de nom d'hôte vérifie. il désactive toutes les vérifications de certificats. Allez vous oblige à définir le nom du serveur égale à la CN dans le cert de ce que vous vous connectez. InsecureSkipVerify va se connecter à un voyou MITM serveur qui prétend à l'avant pour les services réels. Le SEUL usage légitime pour un InsecureSkipVerify est de saisir le cert de l'extrémité distante et débranchez immédiatement.
    InformationsquelleAutor Cornel Damian
  5. 0

    Généralement, Le Domaine DNS de l'adresse URL DOIT correspondre à l'Objet du Certificat de le certificat.

    En des temps anciens, cela pourrait être soit en définissant le domaine du cn du certificat ou par le fait d'avoir le domaine est défini comme un autre Nom de l'Objet.

    Soutien pour le cn est déconseillée pour une longue période (depuis 2000 dans RFC 2818) et le navigateur Chrome ne sera même pas regarder le cn est plus tellement aujourd'hui, vous devez avoir la DNS du Domaine de l'URL comme un autre Nom de l'Objet.

    RFC 6125 qui interdit à la vérification de la cn si SAN de Domaine DNS est présent, mais pas si SAN pour Adresse IP est présente. RFC 6125 répète également que le cn est obsolète qui a déjà été dit dans la RFC 2818. Et l'Autorité de Certification Navigateur Forum pour être présent qui, en combinaison avec la RFC 6125 signifie essentiellement que le cn ne sera jamais vérifiée pour le nom de Domaine DNS.

    InformationsquelleAutor jwilleke