Як зробити запит https з поганим сертифікатом?

Скажіть, я хочу пройти https://golang.orgпрограмно. На даний момент golang.org (ssl) має поганий сертифікат, який видається *.appspot.comОтже, коли я запускаю це:

package main

import (
    "log"
    "net/http"
)

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

Я отримую (як я і очікував)

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

Тепер я хочу довіряти цьому сертифікату сам (уявіть собі виданий сертифікат, де я можу перевірити відбиток пальця тощо): як я можу зробити запит і підтвердити / довірити сертифікат?

Мені, мабуть, потрібно використовувати openssl для завантаження сертифіката, завантаження його у мій файл та заповнення tls.Configstruct !?

Примітка безпеки: вимкнення перевірок безпеки є небезпечним і його слід уникати

Ви можете відключити перевірки безпеки для всіх запитів клієнта за замовчуванням:

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)
    }
}

Ви можете відключити перевірку безпеки для клієнта:

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)
    }
}

Ось спосіб це зробити, не втрачаючи налаштування за замовчуванням DefaultTransport, і не потребуючи підробленого запиту відповідно до коментаря користувача.

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

// Create new Transport that ignores self-signed SSL
customTransport := &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},
}

ОНОВЛЕННЯ

Коротший шлях:

customTransport := &(*http.DefaultTransport.(*http.Transport)) // make shallow copy
customTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

Правильний спосіб (станом на п. 1.13) (надається відповіддю нижче ):

customTransport := http.DefaultTransport.(*http.Transport).Clone()
customTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

Попередження : Тільки для тестування / розробки. Все інше, поступайте на свій страх і ризик !!!

Усі ці відповіді неправильні! Не використовуйте InsecureSkipVerifyдля роботи з CN, який не відповідає імені хоста. Розробники Go нерозумно висловлювалися за те, щоб не відключати перевірки імен хостів (що має законне використання - тунелі, nats, спільні сервери кластерів тощо), а також щось схоже, але фактично повністю ігнорує перевірку сертифіката. Вам потрібно знати, що сертифікат дійсний і підписаний сертифікатом, якому ви довіряєте. Але у звичайних сценаріях ви знаєте, що CN не відповідає імені хоста, з яким ви пов’язані. Для тих, що ServerNameввімкнено tls.Config. Якщо tls.Config.ServerName== remoteServerCN, то перевірка сертифіката буде успішною. Це те, що ти хочеш. InsecureSkipVerifyозначає, що немає аутентифікації; і це дозріло для людини в середині; перемогти мету використання TLS.

Є одне законне використання для InsecureSkipVerify: використовувати його для підключення до хоста та захоплення його сертифіката, а потім негайно відключити. Якщо ви налаштовуєте код на використання InsecureSkipVerify, це, звичайно, тому, що ви не встановили ServerNameналежним чином (його потрібно буде приймати з env var чи чогось іншого - не беріться в живлення щодо цієї вимоги ... робіть це правильно).

Зокрема, якщо ви використовуєте сертифікати клієнтів і покладаєтесь на них для автентифікації, у вас в основному є підроблений логін, який фактично більше не входить у систему. Відмовтеся від коду, який це робить InsecureSkipVerify, або ви дізнаєтеся, що з ним не так важко!

Правильний спосіб зробити це, якщо ви хочете зберегти транспортні налаштування за замовчуванням зараз: (з Go 1.13):

customTransport := http.DefaultTransport.(*http.Transport).Clone()
customTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}
client = &http.Client{Transport: customTransport}

Transport.Clone робить глибоку копію транспорту. Таким чином, вам не доведеться турбуватися про відсутність нових полів, які з часом додаються до Transportструктури.

Якщо ви хочете використовувати параметри за замовчуванням з пакета http, тому вам не потрібно створювати новий об’єкт "Транспорт і клієнт", ви можете змінити, щоб ігнорувати перевірку сертифікатів, як це:

tr := http.DefaultTransport.(*http.Transport)
tr.TLSClientConfig.InsecureSkipVerify = true

Як правило, DNS-домен URL-адреси ОБОВ'ЯЗКОВО відповідає темі сертифіката сертифіката.

У попередні часи це може бути або встановленням домену як cn сертифіката, або встановленням домену як альтернативного імені предмета.

Підтримка cn давно припинялася (з 2000 року в RFC 2818 ), і браузер Chrome навіть більше не буде дивитись на cn, тому сьогодні вам потрібно мати DNS-домен URL як альтернативну назву теми.

RFC 6125, який забороняє перевіряти cn, якщо SAN для DNS-домену присутній, але не, якщо SAN для IP-адреси присутній. RFC 6125 також повторює, що cn застарілий, про що вже говорилося в RFC 2818. І на форумі браузерів сертифікаційного органу, який у поєднанні з RFC 6125 по суті означає, що cn ніколи не перевірятиметься на ім'я домену DNS.