HTTP は TCP 接続を確立し、TFTP は信頼性の低い UDP を使用しているため、HTTP は TFTP よりも信頼性の高い非同期メカニズムを提供します。 また、HTTP サーバーは、TFTP サーバーに比べてフィルタリングとロギングの機能が改善されています。

クライアント側では、HTTP を使用して再同期するためにサーバーに特別な設定は不要です。 GET メソッドで HTTP を使用するための Profile_Rule パラメータ シンタックスは、TFTP に使用するシンタックスに似ています。 標準規格の Web ブラウザが HTTP サーバーからプロファイルを取得できる場合、電話機も同じ動作を実行できる必要があります。

電話機ごとに（ここでは xxxx と表される）、Cisco XML の機能を介してプロビジョニングされます。

XML オブジェクトを SIP Notify パケットにより電話機に送信するか、HTTP Post を使用して電話機の CGI インターフェイス http://IPAddressPhone/CGI/Execute に送信できます。

CP-xxxx-3PCC では、Cisco XML 機能が拡張され、XML オブジェクトを介したプロビジョニングがサポートされます。

<CP-xxxx-3PCCExecute>
        <ExecuteItem URL=Resync:[profile-rule]/>
</CP-xxxx-3PCCExecute>

電話機は XML オブジェクトを受け取ると、プロビジョニング ファイルを [profile-rule] からダウンロードします。 このルールでは、マクロを使用して XML サービス アプリケーションの開発を容易にできます。

複数のプロファイルがあるサーバー上のサブディレクトリは、導入された多数のデバイスを管理するのに便利です。 プロファイルの URL には、次を含めることができます。

• プロビジョニング サーバー名または明示的な IP アドレス。 プロファイルで、プロビジョニング サーバーが名前で識別される場合、電話機は DNS ルックアップを使用して名前を解決します。

• サーバー名の後に標準シンタックス :port を使用して、URL で指定される非標準サーバー ポート。

• 標準 URL 表記を使用して指定され、マクロ展開で管理される、プロファイルが保存されているサーバー仮想ルート ディレクトリのサブディレクトリ。

たとえば、次の Profile_Rule は、ポート 6900 の接続をリスニングしているホスト prov.telco.com で実行中の TFTP サーバーに対し、サーバー サブディレクトリ /cisco/config 内のプロファイル ファイル（$PN.cfg）を要求します。

<Profile_Rule>
tftp://prov.telco.com:6900/cisco/config/$PN.cfg
</Profile_Rule>

各電話機のプロファイルは汎用パラメータで識別できます。その値は、マクロ展開を使用して共通のプロファイル ルール内で参照されます。

たとえば、GPP_B が Dj6Lmp23Q として定義されているとします。

Profile_Rule は次の値になります。

tftp://prov.telco.com/cisco/$B/$MA.cfg

デバイスが再同期されて、マクロが展開されると、000e08012345 の MAC アドレスを持つ電話機は、次の URL にデバイスの MAC アドレスを含む名前を持つプロファイルを要求します。

tftp://prov.telco.com/cisco/Dj6Lmp23Q/000e08012345.cfg

HTTPS は、クライアントとサーバー間の通信を暗号化して、他のネットワーク デバイスからメッセージの内容を保護します。 クライアントとサーバー間の通信本文の暗号化方式は、対称キー暗号化に基づいています。 対称キー暗号化では、クライアントとサーバーが、公開キーまたは秘密キーの暗号化によって保護される安全なチャネルで単一の秘密キーを共有します。

秘密キーで暗号化されたメッセージは、同じキーを使用しないと復号化できません。 HTTPS は、幅広い対称暗号化アルゴリズムをサポートしています。 電話機には、128 ビットの RC4 に加えて、米国暗号化標準（AES）を使用した最大 256 ビットの対称暗号化が実装されています。

HTTPS では、安全なトランザクションで実行されるサーバーとクライアントの認証も提供しています。 この機能により、プロビジョニング サーバーと各クライアントは、ネットワーク上の他のデバイスによりスプーフィングされることはありません。 この機能は、リモート エンドポイントのプロビジョニングでは必須です。

サーバーとクライアントの認証は、公開キーを含む証明書を使って、公開キーまたは秘密キーの暗号化により実行されます。 公開キーで暗号化されたテキストは、対応する秘密キーでなければ復号化できません（その逆も同じです）。 電話機は、公開キーと秘密キーの暗号化で Rivest-Shamir-Adleman（RSA）アルゴリズムをサポートします。

安全な各プロビジョニング サーバーには、シスコが直接署名したセキュア ソケット レイヤ（SSL）サーバー証明書が発行されます。 電話機で実行されるファームウェアは、シスコの証明書のみ有効な証明書として認識します。 クライアントは HTTPS を使用してサーバーに接続すると、シスコで署名されていないサーバー証明書を拒否します。

この方法により、電話機への不正アクセスや、プロビジョニング サーバーをスプーフィングする試みからサービス プロバイダーを保護します。 このような保護を行わないと、攻撃者は電話機を再プロビジョニングして構成情報を取得したり、別の VoIP サービスを使用する可能性があります。 有効なサーバー証明書に対応する秘密キーがない場合、攻撃者は電話機との通信を確立できません。

電話機に対する直接攻撃に加え、攻撃者は標準規格の Web ブラウザまたは別の HTTPS クライアントからプロビジョニング サーバーにアクセスを試み、プロビジョニング サーバーから設定プロファイルを取得する場合があります。 この種の攻撃を防ぐためには、各個々のエンドポイントに関する識別情報を含む、シスコが署名した一意のクライアント証明書を電話機でも伝送します。 デバイスのクライアント証明書を認証できる認証局ルート証明書は、各サービス プロバイダに与えられます。 この認証パスにより、プロビジョニング サーバーは設定プロファイルの不正要求を拒否できます。

サーバー証明書とクライアント証明書を組み合わせると、リモートの電話機とそのプロビジョニング サーバー間のセキュア通信が確保されます。 次の図は、シスコ クライアント、プロビジョニング サーバー、認証局における、証明書、公開キーと秘密キーのペア、および署名ルート認証局の関係と配置を示しています。

図の上半分は、個々のプロビジョニング サーバー証明書の署名に使用されるプロビジョニング サーバー ルート認証局を示しています。 該当するルート証明書はファームウェアにコンパイルされ、電話機は承認されたプロビジョニング サーバーを認証できます。