Pinning Cheat Sheat - Revision history

Jeffrey Walton: Redirected page to Pinning Cheat Sheet

2013-02-13T04:43:55Z

Redirected page to Pinning Cheat Sheet

Jeffrey Walton at 04:41, 13 February 2013

2013-02-13T04:41:43Z

Jeffrey Walton at 04:29, 13 February 2013

2013-02-13T04:29:56Z

Jeffrey Walton at 04:04, 13 February 2013

2013-02-13T04:04:18Z

Jeffrey Walton at 04:00, 13 February 2013

2013-02-13T04:00:19Z

Jeffrey Walton at 03:37, 13 February 2013

2013-02-13T03:37:56Z

Jeffrey Walton at 03:17, 13 February 2013

2013-02-13T03:17:24Z

Jeffrey Walton at 03:15, 13 February 2013

2013-02-13T03:15:55Z

Jeffrey Walton at 02:25, 13 February 2013

2013-02-13T02:25:19Z

Jeffrey Walton: Created pinning cheat sheet

2013-02-13T02:03:41Z

Created pinning cheat sheet

New page

Centralized use of critical infrastructure services such as DNS and CAs in a public CA hierarchy has led to a number of high profile failures in the secure channel. Pandemic abuse of trust and relationships has lured applications and developers to make security related decisions on effectively untrusted user input.

← Older revision		Revision as of 04:43, 13 February 2013
Line 1:		Line 1:
−	Invariant trust of critical infrastructure such as DNS and PKI{X} with a public CA hierarchy has led to a number of high profile failures in the secure channel. This cheat sheet will help developers and organizations navigate the minefield of securing data in transit and by restoring integrity on the channel when a pre-exisiting relationship exists between the user and an organization or service.	+	#REDIRECT [[Pinning Cheat Sheet]]
−
−	~~The~~ [[Pinning Cheat Sheet]] is a technical guide to the Virginia chapter's presentation [[Media:Securing-Wireless-Channels-in-the-Mobile-Space.ppt\|Securing Wireless Channels in the Mobile Space]]. Additional material includes [[Media:pubkey-pin-supplement.pdf\|supplement with code excerpts]], [[Media:pubkey-pin-android.zip\|Android sample program]], [[Media:pubkey-pin-ios.zip\|iOS sample program]], [[Media:pubkey-pin-dotnet.zip\|.Net sample program]], and [[Media:pubkey-pin-openssl.zip\|OpenSSL sample program]]. The cheat sheet is focused on providing clear, simple, actionable guidance for securing the channel in a hostile environment where actors could be malicious and the conference of trust a liability.
−
−	This cheat sheet will not attempt to enumerate and catalogue the failures in the industry, investigate the design flaws in the scaffolding, justify the lack of accountability or liability with the providers, or explain the collusion between, for example, Browsers and CAs. The reader is directed towards [[Media:Securing-Wireless-Channels-in-the-Mobile-Space.ppt\|Securing Wireless Channels in the Mobile Space]] presentation for a sampling of the tangential issues.
−
−	~~== Introduction ==~~
−
−	Secure channels are a cornerstone to users and employees working remotely and on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.
−
−	The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on untrusted input. The situation is somewhat of a paradox: entities such as DNS and CAs are trusted and supposed to supply trusted input; yet the input cannot be trusted. Relying on others for security related decisions is not only bad karma, it violates a number of secure coding principals (see, for example, OWASP's [[Injection Theory]] and [[Data Validation]]).
−
−	Pinning leverages knowledge of the pre-exsiting relationship between the user and an organization or service to help make better security related decisions. In essence, pinning is the act of accepting a host based on their X509 certificate or public key - its a whitelist of known good identities. Effectively, pinning removes the "conference of trust" and identifies the host or service by its public certificate or public key when holding a public/private key pair.
−
−	An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs - when making decisions relating to a peer's identity. For those familiar with SSH, you should realize that public key pinning nearly identical to SSH's <tt>StrictHostKeyChecking</tt> option. SSH had it right the entire time, and the rest of the world is beginning to realize the virtues of directly identifying a host or service by its public key.

@@ Line 1: / Line 1: @@
-Invariant trust of critical infrastructure such as DNS and PKI{X} with a public CA hierarchy has led to a number of high profile failures in the secure channel. This cheat sheet will help developers and organizations navigate the minefield of securing data in transit and by bringing integrity back to the channel when a pre-exisiting relationship exists between the user and an organization or service.
+Invariant trust of critical infrastructure such as DNS and PKI{X} with a public CA hierarchy has led to a number of high profile failures in the secure channel. This cheat sheet will help developers and organizations navigate the minefield of securing data in transit and by restoring integrity on the channel when a pre-exisiting relationship exists between the user and an organization or service.
 The [[Pinning Cheat Sheet]] is a technical guide to the Virginia chapter's presentation [[Media:Securing-Wireless-Channels-in-the-Mobile-Space.ppt|Securing Wireless Channels in the Mobile Space]]. Additional material includes [[Media:pubkey-pin-supplement.pdf|supplement with code excerpts]], [[Media:pubkey-pin-android.zip|Android sample program]], [[Media:pubkey-pin-ios.zip|iOS sample program]], [[Media:pubkey-pin-dotnet.zip|.Net sample program]], and [[Media:pubkey-pin-openssl.zip|OpenSSL sample program]]. The cheat sheet is focused on providing clear, simple, actionable guidance for securing the channel in a hostile environment where actors could be malicious and the conference of trust a liability.
-This cheat sheet will not attempt to enumerate and catalogue the failures in the industry, investigate the design flaws in the scaffolding, or explain the collusion between, for example, Browsers and CAs. The reader is directed towards [[Media:Securing-Wireless-Channels-in-the-Mobile-Space.ppt|Securing Wireless Channels in the Mobile Space]] presentation for a sampling of the tangential issues.
+This cheat sheet will not attempt to enumerate and catalogue the failures in the industry, investigate the design flaws in the scaffolding, justify the lack of accountability or liability with the providers, or explain the collusion between, for example, Browsers and CAs. The reader is directed towards [[Media:Securing-Wireless-Channels-in-the-Mobile-Space.ppt|Securing Wireless Channels in the Mobile Space]] presentation for a sampling of the tangential issues.
 == Introduction ==

@@ Line 1: / Line 1: @@
 Invariant trust of critical infrastructure such as DNS and PKI{X} with a public CA hierarchy has led to a number of high profile failures in the secure channel. This cheat sheet will help developers and organizations navigate the minefield of securing data in transit and by bringing integrity back to the channel when a pre-exisiting relationship exists between the user and an organization or service.
-This cheat sheet is a technical guide to the Virginia chapter's presentation [[Media:Securing-Wireless-Channels-in-the-Mobile-Space.ppt|Securing Wireless Channels in the Mobile Space]]. Additional material includes [[Media:pubkey-pin-supplement.pdf|supplement with code excerpts]], [[Media:pubkey-pin-android.zip|Android sample program]], [[Media:pubkey-pin-ios.zip|iOS sample program]], [[Media:pubkey-pin-dotnet.zip|.Net sample program]], and [[Media:pubkey-pin-openssl.zip|OpenSSL sample program]]. The cheat sheet is focused on providing clear, simple, actionable guidance for securing the channel in a hostile environment where actors could be malicious and the conference of trust a liability.
+The [[Pinning Cheat Sheet]] is a technical guide to the Virginia chapter's presentation [[Media:Securing-Wireless-Channels-in-the-Mobile-Space.ppt|Securing Wireless Channels in the Mobile Space]]. Additional material includes [[Media:pubkey-pin-supplement.pdf|supplement with code excerpts]], [[Media:pubkey-pin-android.zip|Android sample program]], [[Media:pubkey-pin-ios.zip|iOS sample program]], [[Media:pubkey-pin-dotnet.zip|.Net sample program]], and [[Media:pubkey-pin-openssl.zip|OpenSSL sample program]]. The cheat sheet is focused on providing clear, simple, actionable guidance for securing the channel in a hostile environment where actors could be malicious and the conference of trust a liability.
 == Introduction ==
@@ Line 7: / Line 9: @@
 Secure channels are a cornerstone to users and employees working remotely and on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.
-The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on untrusted input. Pinning leverages knowledge of the pre-exsiting relationship between the user and an organization or service to help make better security related decisions. In essence, pinning is the act of accepting a host based on their X509 certificate or public key - its a whitelist of known good identities. Effectively, pinning removes the "conference of trust" and identifies the host or service by its public certificate or public key when holding a public/private key pair.
+The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on untrusted input. The situation is somewhat of a paradox: entities such as DNS and CAs are trusted and supposed to supply trusted input; yet the input cannot be trusted. Relying on others for security related decisions is not only bad karma, it violates a number of secure coding principals (see, for example, OWASP's [[Injection Theory]] and [[Data Validation]]).
 An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs - when making decisions relating to a peer's identity. For those familiar with SSH, you should realize that public key pinning nearly identical to SSH's <tt>StrictHostKeyChecking</tt> option. SSH had it right the entire time, and the rest of the world is beginning to realize the virtues of directly identifying a host or service by its public key.

@@ Line 7: / Line 7: @@
 Secure channels are a cornerstone to users and employees working remotely and on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.
-The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on effectively untrusted input. Pinning leverages knowledge of the pre-exsiting relationship between the user and an organization or service to help make better security related decisions. Effectively, pinning removes the "conference of trust" and identifies the host or service by its public certificate or public key when holding a public/private key pair. An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs - when making decisions relating to a peer's identity.
+The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on untrusted input. Pinning leverages knowledge of the pre-exsiting relationship between the user and an organization or service to help make better security related decisions. In essence, pinning is the act of accepting a host based on their X509 certificate or public key - its a whitelist of known good identities. Effectively, pinning removes the "conference of trust" and identifies the host or service by its public certificate or public key when holding a public/private key pair.
-For those familiar with SSH, you should realize that public key pinning nearly identical to SSH's <tt>StrictHostKeyChecking</tt> option. SSH had it right the entire time, and the rest of the world is beginning to realize the virtues of directly identifying a host or service by its public key.
+An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs - when making decisions relating to a peer's identity. For those familiar with SSH, you should realize that public key pinning nearly identical to SSH's <tt>StrictHostKeyChecking</tt> option. SSH had it right the entire time, and the rest of the world is beginning to realize the virtues of directly identifying a host or service by its public key.

@@ Line 5: / Line 5: @@
 == Introduction ==
-Secure channels are a cornerstone to users and employees on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.
+Secure channels are a cornerstone to users and employees working remotely and on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.
 The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on effectively untrusted input. Pinning leverages knowledge of the pre-exsiting relationship between the user and an organization or service to help make better security related decisions. Effectively, pinning removes the "conference of trust" and identifies the host or service by its public certificate or public key when holding a public/private key pair. An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs - when making decisions relating to a peer's identity.
 For those familiar with SSH, you should realize that public key pinning nearly identical to SSH's <tt>StrictHostKeyChecking</tt> option. SSH had it right the entire time, and the rest of the world is beginning to realize the virtues of directly identifying a host or service by its public key.

← Older revision		Revision as of 03:17, 13 February 2013
Line 7:		Line 7:
	Secure channels are a cornerstone to users and employees on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.		Secure channels are a cornerstone to users and employees on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.

−	The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on effectively untrusted ~~user~~ input. This article is focused on providing clear, simple, actionable guidance for securing the channel in a hostile environment where actors could be malicious and the conference of trust a liability.	+	The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on effectively untrusted input. This article is focused on providing clear, simple, actionable guidance for securing the channel in a hostile environment where actors could be malicious and the conference of trust a liability.

← Older revision		Revision as of 03:15, 13 February 2013
Line 1:		Line 1:
−	Invariant trust of critical infrastructure such as DNS and ~~CAs in~~ a public CA hierarchy has led to a number of high profile failures in the secure channel. This cheat sheet will help developers navigate the minefield of securing data in transit and by bringing integrity back to the channel when a pre-exisiting relationship exists between the user and an organization or service.	+	Invariant trust of critical infrastructure such as DNS and PKI{X} with a public CA hierarchy has led to a number of high profile failures in the secure channel. This cheat sheet will help developers and organizations navigate the minefield of securing data in transit and by bringing integrity back to the channel when a pre-exisiting relationship exists between the user and an organization or service.
		+
		+	This cheat sheet is a technical guide to the Virginia chapter's presentation [[Media:Securing-Wireless-Channels-in-the-Mobile-Space.ppt\|Securing Wireless Channels in the Mobile Space]]. Additional material included [[Media:pubkey-pin-supplement.pdf\|Supplement with code excerpts]], [[Media:pubkey-pin-android.zip\|Android sample program]], [[Media:pubkey-pin-ios.zip\|iOS sample program]], [[Media:pubkey-pin-dotnet.zip\|.Net sample program]], and [[Media:pubkey-pin-openssl.zip\|OpenSSL sample program]].

	== Introduction ==		== Introduction ==

← Older revision		Revision as of 02:25, 13 February 2013
Line 1:		Line 1:
−	~~Centralized use~~ of critical infrastructure ~~services~~ such as DNS and CAs in a public CA hierarchy has led to a number of high profile failures in the secure channel. ~~Pandemic~~ abuse of trust and ~~relationships has lured~~ applications ~~and developers to make~~ security related decisions on effectively untrusted user input.	+	Invariant trust of critical infrastructure such as DNS and CAs in a public CA hierarchy has led to a number of high profile failures in the secure channel. This cheat sheet will help developers navigate the minefield of securing data in transit and by bringing integrity back to the channel when a pre-exisiting relationship exists between the user and an organization or service.
		+
		+	== Introduction ==
		+
		+	Secure channels are a cornerstone to users and employees on the go. Users and developers expect end-to-end security when sending and receiving data - especially sensitive data on channels protected by VPN, SSL, or TLS. While organizations which control DNS and CA have likely reduced risk to trivial levels under most threat models, users and developers subjugated to other's DNS and a public CA hierarchy are exposed to non-trivial amounts of risk. In fact, history has shown those relying on outside services have suffered chronic breaches in their secure channels.
		+
		+	The pandemic abuse of trust has resulted in users, developers and applications making security related decisions on effectively untrusted user input. This article is focused on providing clear, simple, actionable guidance for securing the channel in a hostile environment where actors could be malicious and the conference of trust a liability.