/
264.txt
1131 lines (825 loc) · 60.9 KB
/
264.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
[6] [[SSL]] あるいは [[TLS]] 上で [[HTTP]] を用いる通信、あるいはその[[プロトコル]] [WEAK[(の組み合わせ方)]]
のことを [DFN[[[HTTP/SSL]]]]、[DFN[[[HTTP/TLS]]]]、あるいは [DFN[[[HTTPS]]]]
と呼びます。
;; [[HTTP接続]]や [CODE(URI)@en[[[https:]]]] も合わせて参照してください。
* 仕様書
[REFS[
- [39] '''[CITE@en[RFC 2818 - HTTP Over TLS]] ([TIME[2014-12-15 14:10:09 +09:00]] 版) <http://tools.ietf.org/html/rfc2818>'''
-- [45] [CITE@en[RFC 2818 - HTTP Over TLS]] ([TIME[2014-12-15 14:10:09 +09:00]] 版) <http://tools.ietf.org/html/rfc2818#section-2>
-- [51] [CITE@en[RFC 2818 - HTTP Over TLS]] ([TIME[2014-12-15 14:10:09 +09:00]] 版) <http://tools.ietf.org/html/rfc2818#section-3>
- [68] [CITE[RFC Errata Report]] ([TIME[2015-03-04 17:58:35 +09:00]] 版) <http://www.rfc-editor.org/errata_search.php?rfc=2818>
- [115] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2015-03-05 09:33:40 +09:00]] 版) <https://html.spec.whatwg.org/#encrypted-http-and-related-security-concerns>
- [80] [CITE@en[RFC 6455 - The WebSocket Protocol]] ([TIME[2015-03-11 20:42:50 +09:00]] 版) <http://tools.ietf.org/html/rfc6455#section-4>
- [161] [CITE@en[RFC 6797 - HTTP Strict Transport Security (HSTS)]] ([TIME[2015-05-03 13:27:16 +09:00]] 版) <http://tools.ietf.org/html/rfc6797#section-8.4>
- [159] [CITE@en[RFC 7525 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)]] ([TIME[2015-05-29 03:22:56 +09:00]] 版) <https://tools.ietf.org/html/rfc7525#section-3.6>
- [162] [CITE@en[RFC 7469 - Public Key Pinning Extension for HTTP]] ([TIME[2015-05-05 21:00:37 +09:00]] 版) <https://tools.ietf.org/html/rfc7469#section-2.6>
- [188] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540>
-- [107] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-3.3>
-- [144] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-3.4>
-- [187] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-7>
-- [128] '''[CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-9.2>'''
-- [142] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-10.6>
-- [143] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#appendix-A>
- [203] [CITE@en-US[Fetch Standard]] ([TIME[2016-04-19 01:53:35 +09:00]] 版) <https://fetch.spec.whatwg.org/#concept-http-network-fetch>
]REFS]
;; [87] [[RFC 7230]] が参照されることもありますが、 [CODE(URI)@en[[[https:]]]]
[[URL]] の新たな定義が含まれるのみで、 [[HTTPS]] 本体は [[RFC 2818]]
の規定を参照しています。 ([[RFC 723x]] は [[RFC 2818]] の [CODE(URI)@en[[[https:]]]]
の規定を置き換えていますが、プロトコル自体はなぜか改訂されていません。)
* 呼称
[96] [[TLS]] 上での [[HTTP]] の利用方法について、統一的な呼称はありません。
[[URL scheme]] から [CODE(URI)@en[[[https]]]] ないし [[HTTPS]]
と呼ぶのが最も一般的なようです。
[97] [[HTTPS]] が何の略であるかについては、解釈が揺れており明らかではありません [SRC[>>83]]。
省略形ではなく1つの単語と解するのが適切かもしれません。
[REFS[
- [83] [CITE[HTTPSの「S」は何の略か : mwSoft blog]]
([TIME[2015-03-16 12:37:32 +09:00]] 版)
<http://blog.mwsoft.jp/article/39910926.html>
]REFS]
[98] [[SSL/2.0]] は次のように説明していました。
[FIG(quote)[
[FIGCAPTION[
[86] [CITE[The SSL Protocol]]
<http://web.archive.org/web/19961027104907/http://www3.netscape.com/newsref/std/SSL_old.html>
]FIGCAPTION]
> A special value needs mentioning - the IANA reserved port number for "https" (HTTP using SSL). IANA has reserved port number 443 (decimal) for "https".
]FIG]
[90] [[ポート番号]]に関する[[IANA登録簿]]では、
1994年の >>88 から 2000年の >>91 の間に説明文が書き換わっていますが、
この中間の登録簿が残っていないためどの時点で誰が変更したのかは不明です。
[FIG(quote)[
[FIGCAPTION[
[88] [CITE@en[RFC 1700 - Assigned Numbers]] (1994年)
<https://tools.ietf.org/html/rfc1700>
]FIGCAPTION]
> https 443/tcp https MCom
> https 443/udp https MCom
> # Kipp E.B. Hickman <kipp@mcom.com>
]FIG]
[FIG(quote)[
[FIGCAPTION[
[91] [CITE[PORT NUMBERS]]
(2000年)
<http://web.archive.org/web/20000815053440/http://www.isi.edu/in-notes/iana/assignments/port-numbers>
]FIGCAPTION]
> https 443/tcp http protocol over TLS/SSL
> https 443/udp http protocol over TLS/SSL
> # Kipp E.B. Hickman <kipp@mcom.com>
]FIG]
[FIG(quote)[
[FIGCAPTION[
[92] [CITE[PORT NUMBERS]]
(2001年)
<http://web.archive.org/web/20010519080902/http://www.iana.org/assignments/port-numbers>
]FIGCAPTION]
> https 443/tcp http protocol over TLS/SSL
> https 443/udp http protocol over TLS/SSL
> # Kipp E.B. Hickman <kipp@mcom.com>
]FIG]
[FIG(quote)[
[FIGCAPTION[
[89] [CITE[Service Name and Transport Protocol Port Number Registry]]
([TIME[2015-03-12 02:46:25 +09:00]] 版)
<http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=8>
]FIGCAPTION]
> https 443 tcp http protocol over TLS/SSL '''['''Kipp_E_B_Hickman''']''' '''['''Kipp_E_B_Hickman''']'''
> https 443 udp http protocol over TLS/SSL '''['''Kipp_E_B_Hickman''']''' '''['''Kipp_E_B_Hickman''']'''
> '''['''Kipp_E_B_Hickman''']''' Kipp E.B. Hickman mailto:kipp&mcom.com
]FIG]
[99] [CODE(URI)@en[[[https:]]]] [[URL scheme]] においては一貫して
「Hypertext Transfer Protocol Secure」と説明されているようです。
[FIG(quote)[
[FIGCAPTION[
[95] [CITE[Uniform Resource Identifier (URI) SCHEMES (last updated 2001 August 20)]]
(2001年)
<http://web.archive.org/web/20011113003825/http://www.iana.org/assignments/uri-schemes>
]FIGCAPTION]
> https Hypertext Transfer Protocol Secure '''['''RFC2818''']'''
]FIG]
[FIG(quote)[
[FIGCAPTION[
[94] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]]
([TIME[2015-02-11 04:09:00 +09:00]] 版)
<http://tools.ietf.org/html/rfc7230#section-8.2>
]FIGCAPTION]
> https | Hypertext Transfer Protocol Secure | Section 2.7.2
]FIG]
[FIG(quote)[
[FIGCAPTION[
[93] [CITE[Uniform Resource Identifier (URI) Schemes]]
([TIME[2015-03-06 13:07:57 +09:00]] 版)
<http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml>
]FIGCAPTION]
> https Hypertext Transfer Protocol Secure '''['''RFC7230, Section 2.7.2''']'''
]FIG]
[FIG(quote)[
[FIGCAPTION[
[61] [CITE@ja[OpenService アクセラレータ開発者向けガイド]] ([TIME[2015-04-19 15:00:58 +09:00]] 版) <https://msdn.microsoft.com/ja-jp/library/cc287851(v=vs.85).aspx>
]FIGCAPTION]
>Secure Hypertext Transfer Protocol (HTTPS)
]FIG]
* プロトコル
[24] [[HTTPS]] による通信は、 [[TCP]] のかわりに [[TLS]] over [[TCP]]
を使うことや [[URL scheme]] が違うことを除けば、素の [[HTTP]] と同じです [SRC[>>45]]。
;; [[HTTP]] の通信については [[HTTP接続]]や [[HTTPメッセージ]]、
[[HTTPクライアント]]、[[HTTP鯖]]を参照。
;; [77] 通常の [[HTTP]] では[[対象URL]]に[[絶対URL]]を使わずに[[パス]]以下だけを記述しますし、
それ以外に [[URL scheme]] を明記する[[ヘッダー]]などもありませんから、 [[HTTP]]
か [[HTTPS]] か[[メッセージ]]の内容だけから区別することはできません。
[76] 単一の [[TCP/IP]] の[[末端対末端]]通信上で [[TLS]] を使うのが [[RFC]]
で規定されている [[HTTPS]] ですが、実際には [[TCP/IP]] 以外に
[[HTTP]] [CODE(HTTP)@en[[[CONNECT]]]]、[[SOCKS]]、[[Unix domain socket]]
などの[[トンネル]]が下位層の[[ホップ]]として用いられていることもあります。
;; [[TLS]] を参照。
** HTTP/2 over TLS/1.2
[129] [[HTTP/2]] の実装は、 [[TLS/1.2]] [[以上]]を使わなければ[['''なりません''']] [SRC[>>128]]。
[[BCP 195]] の指針に従う[['''べきです''']] [SRC[>>128]]。
[132] 実装上の制限で [[HTTP/2]] over [[TLS/1.2]] の要件に沿わない場合に
[[TLS]] 折衝を失敗とできない場合もありますから、[[エンドポイント]]は、
[[接続エラー]] [CODE[[[INADEQUATE_SECURITY]]]] によって[[接続]]を直ちに閉じても構いません。
[SRC[>>128]]
[186] [[誤り符号]] [DFN[[CODE[[[INADEQUATE_SECURITY]]]]]] ([CODE[[[0xc]]]])
は、下位層輸送路が最小セキュリティー要件を満たさないことを示します [SRC[>>186]]。
[133] [[HTTP/2]] over [[TLS/1.2]] の[[圧縮]]は、無効としなければ[['''なりません''']]
[SRC[>>128]]。[[TLS]] のような一般的なストリーム圧縮は使っては[['''なりません''']]
[SRC[>>142]]。
;; [[CRIME攻撃]]対策です。
[134] [[HTTP/2]] over [[TLS/1.2]] の[[再折衝]]は、無効としなければ[['''なりません''']]。
[[接続エラー]] [CODE[[[PROTOCOL_ERROR]]]] としなければ[['''なりません''']]。 [SRC[>>128]]
;; [135] そのため長時間の[[接続]]は [[cipher suite]] の暗号化回数制限に当たるかもしれません
[SRC[>>128]]。その場合は[[接続]]を新たに開く必要があります。
[136] ただし[[クライアント証明書]]の機密性保持のために[[再折衝]]を使うことはできます。
[[再折衝]]は[[接続序文]]の送信の前に行わなければ[['''なりません''']]。
[[サーバー]]は、[[接続]]の確立の直後に[[再折衝]]要求があったら、
[[クライアント証明書]]を要求する[['''べきです''']]。 [SRC[>>128]]
;; [137] [[再折衝]]制限のため、特定の[[資源]]への要求に対して[[再折衝]]を使うことができません。
将来の改訂でそのような利用にも対応するかもしれません。
あるいは[[サーバー]]は [CODE(HTTP)[[[HTTP_1_1_REQUIRED]]]] を送信し、
[[再折衝]]に対応するプロトコルを使うよう求めることができます。 [SRC[>>128]]
[183] [[Chrome]] は[[再折衝]]を無効にしているようで、[[サーバー]]が[[再折衝]]を求めると
[[TLS fatal alert]] [CODE[[[no_renegotiation]]]] により切断します。
([[HTTP]] レベルのエラーは送信しません。) [[サーバー]]の[[接続序文]]の送信前でも、
受け入れられないようです。 [[Firefox]] は[[再折衝]]を有効にしているようで、
[[接続序文]]の前後に関わらず、必要に応じて[[クライアント認証]]の[[ダイアログ]]も表示します。
[TIME[2015-10-11T14:15:42.800Z]]
[138] [[HTTP/2]] over [[TLS/1.2]] の実装は、
ephemeral finite field [[DHE]] を使う [[cipher suite]] では最低2048ビット、
ephemeral [[ECDHE]] を使う [[cipher suite]] では最低224ビットの
ephemeral key exchange size に対応しなければ[['''なりません''']]。
[[クライアント]]は [[DHE]] サイズ最大 4096 ビットまで受け入れなければ[['''なりません''']]。
[[エンドポイント]]は、下限より小さな鍵長の折衝を[[接続エラー]]
[CODE[[[INADEQUATE_SECURITY]]]] として構いません。 [SRC[>>128]]
[139] [[HTTP/2]] over [[TLS/1.2]] の実装は、
ブラックリスト [SRC[>>143]] の [[cipher suite]] を使う[['''べきではありません''']] [SRC[>>128]]。
[[エンドポイント]]は、ブラックリストの [[cipher suite]]
が使われていたら、[[接続エラー]] [CODE[[[INADEQUATE_SECURITY]]]]
としても構いません [SRC[>>128, >>143]]。ブラックリストにない [[cipher suite]]
に[[折衝]]された時にこのエラーとしては[['''なりません''']] [SRC[>>128]]。
[140] [[HTTP/2]] over [[TLS/1.2]] の実装は、[[cipher suite]]
[CODE[[[TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]]]]
を [[P-256 elliptic curve]] で対応しなければ[['''なりません''']] [SRC[>>128]]。
;; [141] [[クライアント]]は、[[HTTP/2]] に対応しない[[サーバー]]のためにブラックリストの
[[cipher suite]] への対応も[[広告]]するかもしれません。 [SRC[>>128]]
** Opportunistic Security for HTTP/2
[227] [[Opportunistic Security for HTTP/2]] は、 [[HTTP/2]] over [[TLS]]
を [CODE(URI)@en[http:]] [[URL]] の[[要求]]と[[応答]]の送受信に使うものです。
[CODE(URI)@en[https:]] [[URL]] の場合とは若干の違いがあります。
;; [[Opportunistic Security for HTTP/2]] 参照。
* 接続の開始
[46] [[クライアント]]は、[[鯖]]の適切な[[ポート]]への[[接続]]を初期化してから、
[[TLSハンドシェイク]]を始める [[TLS]] [CODE[[[ClientHello]]]] [[メッセージ]]を送信するべきです。
[SRC[>>45]]
;; [110] [[TLS]] より前にそれ以外のデータを送受信することはできません。
([[TCP接続]]の途中の[[要求]]や[[応答]]から [[TLS]] に切り替えるような使い方はできません。)
[111] [[クライアント]]は、接続先が [[DNSホスト名]]なら、 [CODE[[[ClientHello]]]]
に [[SNI]] を含める必要があります。 [[HTTPS]] の実装は、 [[SNI]]
に対応しなければなりません [SRC[>>159]]。 [[WebSocket]] [SRC[>>80]] や
[[HTTP/2]] [SRC[>>128]] の場合は、 [[SNI]]
を使わなければ[['''なりません''']]。 [[HTTP/2]] [[TLS]] 実装は [[SNI]]
に対応しなければ[['''なりません''']] [SRC[>>128]]。
;; [113] [[HTTP/1.1]] [[以下]]の [[HTTPS]] の仕様上は [[SNI]]
への対応は要求されていませんが、
対応しない[[クライアント]]は [[Web互換]]ではありません。
;; [130] [[IPアドレス]]への接続時にどうするべきかは不明です。
;; [114] [[サーバー]]はこれが[[実効要求URL]]と一致しているか検査する必要がありますが、
実際にはしていない[[サーバー]]が多いようです。[[実効要求URL]]や [[SNI]] を参照。
[112] [[クライアント]]と[[サーバー]]は、互いの[[証明書]]を検査する必要があります (後述)。
[81] [[WebSocket]] over [[TLS]] ([CODE(URI)@en[[[wss:]]]]) でも、
本節のようにしなければ[['''なりません''']] [SRC[>>80]]。
[164] [[TLSハンドシェイク]]は、成功裏に完了するか、失敗するかのいずれかです。
失敗した場合は、 [[HTTP]] の処理を続けることはできません。なお成功の場合でも、
(fatal ではない) [[TLS error alert]] を受信しているかもしれません。
[165] [[HSTS]] や [[PKP]] が適用される[[ホスト]]では、
(エラーのレベルに関わらず) エラーがあれば[[接続]]を失敗として閉じなければなりません
[SRC[>>161, >>162]]。
;; それぞれの項を参照。
[163] [[TLSハンドシェイク]]が完了したら、データの送受信 (>>47) を開始できます。
** ALPN
[155] [[クライアント]]は、 [[ALPN]] によって [CODE[[[h2]]]], [CODE[[[http/1.1]]]]
を指定するべきと思われます。
[156] [[サーバー]]は、 [[ALPN]] が用いられている時は [CODE[[[h2]]]] または
[CODE[[[http/1.1]]]] があれば [[HTTP/2]] と [[HTTP/1.1]] のいずれか適切な方を選択し、
いずれもなければ [[fatal alert]] を返すべきと思われます。
[[ALPN]] が用いられていない時は [[HTTP/1.1]] を使うべきと思われます。
[122] [[ALPN]] の [[IANA登録簿]]には、 [CODE[[[http/1.1]]]] が [[HTTP/1.1]]
用に登録され、 [[RFC 7230]] が出典となっています。
;; [157] しかし現時点でこの値の利用方法は定義されていません。
自明だから登録以上の説明は不要だということなのでしょうか。 [TIME[2015-05-18T13:09:39.900Z]]
;; [158] 例えば [CODE[[[http/1.1]]]] が指定された時に [[HTTP/1.0]] や [[HTTP/0.9]]
の[[要求]]が送られてきたらどう処理するべきかは不明です。
[145] [[HTTP/2]] の実装は、 [[ALPN]] を使わなければ[['''なりません''']] [SRC[>>144]]。
[124] [[HTTP/2クライアント]]が [CODE(URI)@en[[[https:]]]] [[URL]]
に接続する時は、 [[ALPN]] で[[プロトコル識別子]] [CODE[[[h2]]]]
を使います [SRC[>>107]]。
;; [146] [[ALPN]] を使わない [[HTTP/2]] (らしき) 接続を[[サーバー]]が拒絶しなければならないのかどうかはあまり明確ではありません。
[[cross-protocol attack]] を防止するためには、拒絶するべきでしょう。
;; [147] [[ALPN]] を (エラーすら) [[サーバー]]が返さなかった時に、
[[HTTP/2]] [[クライアント]]がどうするべきなのかは明確ではありません。
[[相互運用性]]と [[cross-protocol attack]] 防止の観点からは、
エラーとして切断するべきでしょうか。
[125] [[ALPN]] の [[IANA登録簿]]には、 [CODE[[[h2c]]]] も登録されています。
これは [[HTTP/2]] over [[TLS]] を表しています。[[クライアント]]は、この値を送っては[['''なりません''']]。
[[サーバー]]は、この[[プロトコル]]を選択しては[['''なりません''']]。 [SRC[>>107]]
;; [126] [[ALPN]] の [[IANA登録簿]]には、 [[HTTP/2]] の過去の版を表す
[CODE[[[spdy/1]]]], [CODE[[[spdy/2]]]], [CODE[[[spdy/3]]]] も登録されています。
また [[HTTP/2]] の過去の版では [CODE[[[h2-11]]]] のような暫定的な値を使っていました。
古い実装はこうした値に対応しているかもしれませんが、近いうちに削除されると思われます。
[154] [[HTTP]] の版の選択については、[[プロトコルの版]]を参照。
[127] [[利用者エージェント]]が送信するプロトコルの値は、[[fingerprinting vector]] です。
[180] [[Firefox]] は、 [CODE[[[h2]]]], [CODE[[[spdy/3.1]]]],
[CODE[[[http/1.1]]]] を (この順で) 指定するようです。 [TIME[2015-09-26T13:31:35.400Z]]
[HISTORY[
[171] [[Firefox]] は、 [CODE[[[h2-16]]]], [CODE[[[h2-15]]]],
[CODE[[[h2-14]]]], [CODE[[[h2]]]], [CODE[[[spdy/3.1]]]], [CODE[[[http/1.1]]]]
を (この順で) 指定するようです。 [TIME[2015-08-04T09:58:57.100Z]]
]HISTORY]
[172] [[Chrome]] は、 [CODE[[[http/1.1]]]], [CODE[[[spdy/3.1]]]],
[CODE[[[h2-14]]]], [CODE[[[h2]]]] を (この順で) 指定するようです。 [TIME[2015-08-04T10:12:20.100Z]]
[184] [[WebSocket]] の接続の時、 [[Firefox]] は [[ALPN]] と [[NPN]]
を指定します。 [[ALPN]] では [CODE[[[http/1.1]]]] のみを指定します。
[[Chrome]] は [[NPN]] のみを指定します。 [TIME[2015-10-11T14:38:05.000Z]]
[185] [[WebSocket]] の接続で (候補に指定されていないにも関わらず)
[[サーバー]]が [[ALPN]] で [CODE[[[h2]]]] を選択すると、 [[Firefox]]
は [[HTTP/2]] に変換した [[WebSocket handshake]] を送信してきます。
ただし [CODE[[[connection]]]] や [CODE[[[upgrade]]]] は含まれていない不完全なものです。
なお [CODE[[[:scheme]]]] は [CODE[[[https]]]] になります。
[TIME[2015-10-11T14:39:15.100Z]]
* 証明書による認証
[167] [[TLS]] の実装は、 [[TLS]] としての[[証明書]]・[[証明書鎖]]の検査の他に、 [[HTTPS]]
において規定される次のような検査も行う必要があります。
** サーバー証明書の検査 (クライアント側)
[54] [[クライアント]]は、[[サーバー証明書]]について [[service identity]]
の検証を行わなければ[['''なりません''']]。
;; [[service identity]] を参照。
[116] [[利用者エージェント]]は、[[証明書]]の[[誤り]]を[[利用者]]に報告する[['''べき''']]です。
[[利用者エージェント]]は、誤った[[証明書]]により送られた[[資源]]の[[ダウンロード]]を拒むか、
または[[暗号化]]されずに送られた場合のように動作するかのいずれかとしなければ[['''なりません''']]。 [SRC[>>115]]
[EG[
[118] [[自己署名証明書]]が使われていた場合、暗号化されていなかったものとして扱うことができます。([[利用者]]に警告して[[利用者]]の判断においてであっても) 通常通りに表示してしまうと、
[[利用者]]を騙して [[MITM]] を受け入れさせてしまうかもしれません。 [SRC[>>115]]
]EG]
[117] [[利用者エージェント]]は、あるページに再訪した時に前より[[暗号化]]が安全で無くなっている場合に、
[[利用者]]に問題があるかもしれないと警告する[['''べきです''']]。 [[MITM攻撃]]の虞があります。 [SRC[>>115]]
[EG[
[119] [[ブックマーク]]から再訪したサイトが[[自己署名証明書]]に変わっていると、
[[MITM攻撃]]を受けた可能性があると警告する方が良いかもしれません [SRC[>>115]]。
]EG]
[160] [[クライアント]]は、 [[PKP]] を実装する場合、 [[PKP]] の検査を行う必要があります。
検査に失敗した場合は、接続を閉じることになります。報告を送信する場合もあります。
;; [[PKP]] を参照。
[131] [[HTTP/2]] で[[接続]]を再利用する際には、[[接続]]確立時と同様に[[要求]]の[[ホスト]]を[[証明書]]に対して検証しなければならないことになっています。
;; [[HTTP接続]]参照。
[216] [[WebDriver]] には、[[自己証明証明書]]や信頼できない[[証明書]]を受け入れることを指定する
[CODE[acceptSslCerts]] オプションがあります。ただし、「信頼できない[[証明書]]」
の具体的な範囲は規定されていません。おそらくは、[[利用者]]が画面から手動で受け入れることを選択できるものと同等の機能が提供されることが期待されています。
[217] [CODE[wget]] や [CODE[curl]] のような [[Webブラウザー]]以外の[[利用者エージェント]]にも、
[[証明書]]の[[検証]]を飛ばしたり、結果を無視したりするオプションが用意されていることがよくあります。
残念ながら、実用上はこのようなオプションが不可欠かもしれません。
** クライアント証明書の検査 (サーバー側)
[64] [[鯖]]は普通は[[クライアント]]の [[identity]] がどうであるべきか
(どのような[[証明書]]を有しているべきか) についての外部情報を有していませんから、
[[クライアント]]について検査することはできません。 [SRC[>>51]]
[65] [[鯖]]がそのような外部情報を有している場合には、
[[鯖]]の[[証明書]]の検査と同様の [[identity]] の検査を行う[['''べき''']]です。
[SRC[>>51]]
;; [66] これは一般的には[[SSLクライアント認証]]などと呼ばれているようです。
[[装置]]に埋め込まれた特定の[[クライアント]]や、[[イントラネット]]など、
[[クライアント]]が限定される場合でかつ[[認証]]を行いたい場合に事前に[[クライアント証明書]]を配布しておき、
これを[[鯖]]側で検査して[[接続]]を受け入れるかどうか判断するものです。
;; [121] なお、当然ながらこれら[[証明書]]による [[identity]] の検査の他に、
[[証明書]]の有効期限や発行元など [[TLS]] / [[ドメイン名]] / [[クライアント認証]]に依存しない[[証明書]]一般に関する検査も行う必要があります。
(それらの検査を通過できない場合も、[[利用者]]の判断により通信を継続させるオプションを提供する実装が一般的です。)
;; [166] [[TLSクライアント認証]]も参照。
[228] [[Opportunistic Security for HTTP/2]] では[[クライアント認証]]を行わないことになっています。
[[Opportunistic Security for HTTP/2]] 参照。
* ネットワークエラーとHTTPS状態
[204] [[TLS接続]]の確立でエラー ([[TLS]] のエラー、認証のエラー、
エラーとして扱うべき警告、エラーとして扱うべき古い [[TLS]] の版、
エラーとして扱うべき弱い [[cipher suite]] など) が検出された場合、
[[ネットワークエラー]]とする [SRC[>>203]] ことになっています。
[205] そうでない場合、 [[HTTP-network fetch]] が返す[[応答]]において、
[F[HTTPS状態]]を [CODE[modern]] または [CODE[deprecated]] のいずれかに設定することになっています
[SRC[>>203]]。
[206] どちらにするかは、[[利用者エージェント]]の基準で決めることができます [SRC[>>203]]。
廃止予定で移行期間中にある弱い [[cipher suite]] などの場合は [CODE[deprecated]]
を使い、そうでない場合は [CODE[modern]] を使うことが期待されています。
;; [[HTTPS状態]]も参照。
[207] かつては、エラーがあった場合でも (エラーの種別にもよりますが)
[[利用者]]の指示により一時的に[[ネットワークエラー]]とせずに処理を続行させることができる実装が一般的でした。
現在でも一部そのような機能が残っている [[Webブラウザー]]もありますし、
[[認証]]の一部を省略するオプションを用意している[[クライアント]]の[[プログラム]]や[[ライブラリー]]も広く流通しています。
しかしながら、 (悪意の有無はともかく) [[利用者]]に十分な理解をさせずにセキュリティー的に問題のあるそうした操作を強いる
[[Webサイト]]が増えて激しく非難されたこともありました。
こうしたオプションは廃止したり、一般の[[利用者]]が使いにくくしたりする流れとなってきています。
* データの送受信
[47] [[HTTP]] のデータは、 [[TLS応用データ]]として送信しなければ[['''なりません''']]
[SRC[>>45]]。
[58] [[TLS応用データ]]として送受信される [[HTTP接続]]上の [[HTTP要求]]や
[[HTTP応答]]の処理は、基本的には [[TCP]] 上の [[HTTP]] の場合と同じです。
;; [[HTTP接続]]参照。
[152] [[HTTP/1.1]] [[以下]]では、 [[TLS handshake]] の完了後、すぐに通常の
[[HTTP]] の[[要求]]や[[応答]]を送受信できる状態となります。
[153] [[HTTP/2]] では、 [[TLS handshake]] の完了後、
まず[[接続序文]]の送受信を行わなければ[['''なりません''']] [SRC[>>107, >>144]]。
[56] [[HSTS]] や [[PKP]] の処理は、 [[TLS]] レベルで誤りや警告があった時には行わないことになっています。
;; [[HSTS]], [[PKP]] 参照。
;; [57] [[TLS]] の誤りや警告は、 [[HSTS]] 以外の通常の [[HTTP]] の機能を処理する上では当然に無視されるものもありますし、
[[サーバー証明書]]の問題などを無視するよう[[利用者]]が指示している場合もあります。
通常の [[HTTP]] としての処理は行うものの、 [[HSTS]] の処理は飛ばすことになります。
[178] 接続中に[[クライアント認証]]を目的とした[[再折衝]]が行われることがあります。
;; [[TLSクライアント認証]]を参照。
[179] ただし [[HTTP/2]] では禁止されています (>>134, >>136)。
* 接続を閉じる
[48] [[TLS]] の実装は、[[接続]]を閉じる前に [[TLS]] [[closure alert]]
の交換をはじめなければ[['''なりません''']]。妥当な [[closure alert]]
を受信したら、その[[接続]]からそれ以上データを受信しないと仮定して構いません。
[[TLS]] の実装は、 [[closure alert]] の送信後に、相手が [[closure alert]]
を送信するのを待たずに[[接続]]を閉じ ([[incomplete close]] し) ても構いません。
[[クライアント]]は、それ以上のデータを受信できなくなった時、
[[鯖]]の [[closure alert]] を待たずに[[接続]]を閉じて構いません。
[[鯖]]は、 [[closure alert]] の送信後に[[接続]]を閉じて構いません。
[[鯖]]は、[[クライアント]]による [[incomplete close]] に備える[['''べきです''']]。
そのような実装は、[[セッション]]を再利用することにしても構いません。
これは取り扱うメッセージデータをすべて受信したと ([[HTTPメッセージ]]の境界の判定などにより)
分かる場合にのみ行う[['''べきです''']]。
[[クライアント]]は、 [[incomplete close]] を検出したら、 [[graceful]] に回復する[['''べき''']]です。
その場合 [[TLSセッション]]を再開 ([[resume]]) して構いません。
[[鯖]]は [[incomplete close]] された[[TLSセッション]]を再開 ([[resume]])
[RUBYB[できる]@en[willing to]][['''べき''']]です。 [SRC[>>45]]
[50] 実装は、妥当な [[closure alert]] を受信せずに[[接続]]が閉じられた場合
([[premature close]]) には、[[セッション]]を再利用しては[['''なりません''']]。
[[クライアント]]は、 [[premature close]] を[[誤り]]として扱い、
受信したデータは途中で切れてしまっているかもしれないものと扱わなければ[['''なりません''']]。
一般に [[HTTP]] ではデータが途中で途切れたかどうか判定して誤りから回復することが認められてはいますが、
[[HTTPS]] では、 [CODE(HTTP)@en[[[Content-Length:]]]] が無いため[[鯖]]が[[接続]]を閉じて終端を表したのか攻撃者が[[接続]]を不正に閉じたのかわからない場合や、
[CODE(HTTP)@en[[[Content-Length:]]]] よりも実際のデータが短く[[鯖]]の設定に誤りがあるのか攻撃者が[[接続]]を不正に閉じたのかわからない場合もあり、注意が必要です。
[[クライアント]]は、 [CODE(HTTP)@en[[[Content-Length:]]]] で指定された分のデータを受信し終えたものについては、
[[premature close]] であっても完了したものと扱う[['''べきです''']]。 [SRC[>>45]]
[177] [[TLS 1.1]] 以後、 [[premature close]] 時にも[[セッション再開]]を認めるよう
(実態に合わせて) 仕様変更されています。 [[HTTPS]] 仕様はその後改訂されていないのですが、
変更の趣旨を考えると、[[セッション]]再利用の禁止は失効していると考えるべきでしょう。
;; [[closure alert]] も参照。
;; [31] [[HSTS]] も参照。
* URL scheme
[9] [[HTTPS]] の [[URL scheme]] は [CODE(URI)@en[[[https:]]]] です。
;; [CODE(URI)@en[[[https:]]]] を参照。
* ポート
[210] [[HTTPS]] [[プロトコル]]としての[[ポート番号]]の制限はありません。
[EG[
[211] 理論上は、例えば [N[80]] を使うことも (不自然ですが) 可能です。
]EG]
;; [198] [[port blocking]] も参照。
[49] [[HTTP]]/[[TLS]]/[[TCP]]/[[IP]] の[[既定のポート]]は、 [DFN[[N[443]]]]
です [SRC[>>45]]。
[231]
[[HTTP Web Push]] は [N[1001]]
をも使っています。
* 素の HTTP と異なる動作
[200] [[素のHTTP]]と[[HTTPS]]とで、
[[HTTP]] [[プロトコル]]やそれを通じてやり取りされる[[文書]]の処理で、
異なる動作が求められることがあります。
[FIG(list)[
- [201] [[HTTPS]] では、[[応答]]に [[HSTS]] [[ヘッダー]]を含める[SHOULD[べきです]]。
[[素のHTTP]]では含めては[MUST[なりません]]。
- [[secure context]]
]FIG]
* メタ変数 [CODE(CGI)@en[HTTPS]]
- [1] [[SSL]] or [[TLS]] が使われた [[HTTP]] 要求に伴った [[CGI]] のスクリプトに与えられることがある[[メタ変数]]です。 (標準化はされていません。)
- [2] 値はサーバーのソフトウェアによって [CODE(CGI)[1]] だったり [CODE(CGI)[ON]] だったり [CODE(CGI)[on]] だったり、空文字列あるいは値未設定だったり [CODE(CGI)[OFF]] だったり [CODE(CGI)[off]] だったり色々のようです。そもそもこのメタ変数を実装していないサーバーもあります。
- [3] [CODE[iPlanet-WebServer-Enterprise/4.1]] は [CODE(CGI)[ON]] / [CODE(CGI)[OFF]] らしいです。
- [4] このメタ変数を提供しないサーバーでも [CODE(CGI)[[[SERVER_PORT_SECURE]]]] が参考になるかもしれません。
[DEL[
[5]
>>1 一応 [[RFC 3875]] で規定されました。
]DEL]
[7] [[CGI]] ([[RFC 3875]]) の規定により、[[プロトコル]]と [[URL scheme]] が異なる時に
[[URL scheme]] と同名の[[メタ変数]]を定義してよいとされており、[[メタ変数]]
[CODE(CGI)@en[[[HTTPS]]]] がこれに合致します。
;; 同仕様上、それ以外の場面でそれを定義してはならないとはされていませんし、
設定する値についても規定が無いので、 >>2 のどの値でも仕様と矛盾はしていません。
** 実装
[8] [[HTTP::Request::AsCGI]] は [CODE[[[ON]]]] または [CODE[[[OFF]]]] を設定します。
* 逆串によるプロトコル情報ヘッダー
[13] [[HTTPS]] を [[HTTP]] として[[転送]]する[[逆串]]は、元々が [[HTTP]]
だったか [[HTTPS]] だったかの区別を保持するために[[要求]]に[[ヘッダー]]を付加することがあります。
[14] そのような[[ヘッダー]]としては次のものが知られています。
[FIG(middle list)[
- [CODE(HTTP)@en[[[X-Forwarded-HTTPS:]]]]
- [CODE(HTTP)@en[[[X-Forwarded-Proto:]]]]
- [CODE(HTTP)@en[[[X-Forwarded-Protocol:]]]]
- [CODE(HTTP)@en[[[X-Forwarded-Scheme:]]]]
- [CODE(HTTP)@en[[[X-Forwarded-Ssl:]]]]
- [CODE(HTTP)@en[[[CF-Visitor:]]]]
- [CODE(HTTP)@en[[[Forwarded:]]]]
- [CODE(HTTP)@en[[[Front-End-Https:]]]]
- [CODE(HTTP)@en[[[X-Url-Scheme:]]]]
- [CODE(HTTP)@en[CloudFront-Forwarded-Proto:]]
]FIG]
[25] [[Webアプリケーション]]提供者が最外 (最も[[クライアント]]側) に配置する[[逆串]]で
[[HTTPS]] の [[TLS]] を終端させ、内部の[[アプリケーション鯖]]には [[HTTP]]
で[[転送]]するように設定されていることがよくあります。また場合によっては別の
[[TLS]] 接続により [[HTTPS]] で[[アプリケーション鯖]]に接続するケースもあります。
* 串
[26] ([[逆串]]ではない順方向の) [[串]]を使う時は普通は [[HTTPS]] の通信は
[CODE(HTTP)@en[[[CONNECT]]]] [[要求メソッド]]を使って[[トンネル]]を通過させる形とし、
[[串]]により変更されないようにします。
[27] [[串]]の前後でそれぞれ [[HTTP]] over [[TLS]] を使うこともできるかもしれませんが、
[[串]]は[[鯖]]の[[証明書]]を持っていませんから、[[クライアント]]から見ると不正な
[[証明書]]を使った [[TLS]] 通信に見えます。 (これは [[MITM]] 攻撃そのものです。)
特殊な場面では[[串]]の[[証明書]]を[[クライアント]]が信頼することで回避できるかもしれませんが、一般的には使えない方法です。
[28] [[串]]と[[クライアント]]の間が信頼できるネットワークの場合は[[串]]で [[TLS]]
を終端させ[[串]]と[[クライアント]]の間は素の [[HTTP]] とすることもできるかもしれませんが、
そのような使い方も一般的ではありません。
[30] 仕様に適合しない不正な[[串]]の悪影響を避けるために敢えて [[HTTPS]]
を使うこともあります。
[29] 素の [[HTTP]] の通信を[[串]]により中継する場合に、[[串]]と[[クライアント]]の間で
[[HTTPS]] を使うことは可能です。
* 素の HTTP との混在
[23] [[HTTPS]] で送信された[[文書]]における素の [[HTTP]] の[[資源]]の参照には色々な制限があります。
;; [[Mixed Content]] や [[Referrer]] や [CODE(HTTP)@en[[[upgrade-insecure-requests]]]]
を参照。
* プライバシー
[173] [[ブラウザー拡張]]の類で、閲覧中のページの [[URL]] を自動的に送信するもの
(例えば[[ソーシャルブックマーク]]サービスで、サービスの[[サーバー]]から [[URL]]
に関する情報を自動的に取得するもの) の中には、[[プライバシー]]への配慮から、
[CODE(URI)@en[[[https:]]]] [[URL]] は既定では自動的な取得対象から除外する設定になっていることもありました。
[174] [[HTTPS]] が例外ではなく基本となりつつある現在では、
そのような設定では実用的ではないかもしれません。
;; [175] だとしても、 [CODE(URI)@en[[[https:]]]] の [[URL]] を[[平文]]で他に自動送信するのは今後も避けるべきでしょう。
* レンダリング
[176] [[Web Security Context]] 仕様書に表示に関する規定があります。
* 歴史
** Netscape HTTPS
[43] [[HTTPS]] は [[SSL]] の開発者である [[Netscape]]
が最初に実装しました。
;; [[SSL]] の最初の仕様書である [[SSL/2.0]] には[[アプリケーション層プロトコル]]の例として
[[HTTP]] を示しています。それ以上に特別に [[HTTPS]] について規定した仕様書はこの時代には存在していなかったようです。
[52] [[SSL/2.0]] および [[SSL/3.0]] には、 [[HTTP]] over [[SSL]] ([[https]]) 用に
[CODE[[[443]]]] 番[[ポート]]が [[IANA]] に登録されている旨の記載がありました。
;; [53] [CODE(HTTP)@en[[[https:]]]] [[URL scheme]] に関する明示的な規定はこの時代には存在していないようです。
** 他の HTTP over SSL の提案: [CODE(HTTP)@en[Upgrade: TLS/1.0]] (RFC 2817)
[15] [[Netscape]] によって [[SSL]] と同時に実装された現在の [[HTTPS]]
の他にも、 [[SSL]] と [[HTTP]] を組み合わせる方法はいくつか提案されていました。
しかし結局いずれも広く実装されるには至りませんでした。
;; [22] [[SSL]] を使わない[[暗号化]]の仕組みである [[S-HTTP]] も提案されていましたが、
やはり普及しませんでした。
[20] [[RFC 2817]] は、[[平文]]の [[HTTP]] で [CODE(HTTP)@en[[[Upgrade:]] [DFN[[[TLS/1.0]]]]]]
と指定することで [[HTTP]] over [[TLS]] に切り替える [SRC[>>16]] ことを提案していました。
その場合は [CODE(HTTP)[[[101]]]] [[応答]]を返してから、
[[TLS]] による通信に切り替わることになっていました [SRC[>>16]]。
;; [21] 多くの [[IETF]] の[[プロトコル]]で採用されている [CODE@en[[[STARTTLS]]]]
方式と似ています。
;; [44] [[RFC 2818]] ([[HTTPS]]) が[[情報提供RFC]]なのに対し、 [[RFC 2817]]
は [[IETF]] [[標準化過程]]の[[提案標準]]でした。
;; [75] [[TLS]] のプロトコルの版に関しては [[protocol (HTTP)]] を参照。
[17] [[RFC 2817]] は、それが広く普及すれば [[HTTP/TLS]] も従来の [[HTTP]] も共に
[CODE(URI)@en[[[http:]]]] [[URL]] で識別できるようになると述べています [SRC[>>16 8.1]]。
[78] [[IPP/1.1]] は (従来の [[IPP/1.0]] の [[HTTPS]] 方式にかわって)
本方式を採用していました。2015年になってようやく [[HTTPS]] 方式が [[RFC 7472]]
として出版されました。 (しかし本方式も廃止はされておらず、一部の実装に問題があって
[[RFC 2817]] 自体には問題が無かったというのが [[IETF]] の立場のようです。)
;; [[IPP]] 参照。 [[RFC 7472]] には本方式の問題点の指摘も含まれています。
[100] [[Apache]] が本方式を実装していたようですが、対応している[[クライアント]]が無かっただけでなく、
実用上使いにくそうとの指摘 [SRC[>>102]] もありました。
[18] 本方式について [[RFC 6454]] は、[[同一起源方針]]における [[URL]] による [[trust]]
の観点から、[[文書]]が [[TLS]] の必要性を明示できないような仕様には問題があると指摘
[SRC[>>19]] しています。
[74] [[RFC 2817]] は、 [CODE(HTTP)@en[[[Upgrade:]]]] 方式が普及すれば、
[[クライアント]]に「ローカルネットワーク外への [CODE(HTTP)@en[[[POST]]]] には [[TLS]]
を必須とする」、[[鯖]]に「このフォームは [[TLS]] でのみ提供する、
[[TLS]] でのみ[[提出]]させる」といった設定が設けられるようになるかもしれない [SRC[>>16]]
と説明していました。 [[TLS]] を使うか否かは[[ネットワーク]]の問題であり、
[[文書]]中の [[URL]] の記述ではなく、[[クライアント]]と[[鯖]]の設定で選ぶものと考えていたのかもしれません。
[40] いずれにせよこの方式は支持を集められませんでした。
[73] 本方式は[[ポート]]が1つで済むことの他、 [[virtual hosting]]
に対応していることが利点として挙げられていました [SRC[>>16]]。 [[HTTPS]]
の [[virtual hosting]] 対応は遅れましたが、2010年代半ばになってようやく
[[SAN]] 対応が普及してきています。 (当時既に [[SAN]] は存在していたのですから、
実は大きな利点とは言えない気がします。)
[REFS[
- [16] [CITE@en[RFC 2817 - Upgrading to TLS Within HTTP/1.1]] ([TIME[2012-01-09 20:05:09 +09:00]] 版) <http://tools.ietf.org/html/rfc2817>
- [19] [CITE@en[RFC 6454 - The Web Origin Concept]] ([TIME[2011-12-12 09:13:37 +09:00]] 版) <http://tools.ietf.org/html/rfc6454#section-3.1.1>
- [103] [CITE@en[276813 – '''['''RFE''']''' Support RFC 2817 / TLS Upgrade for HTTP 1.1]] ([TIME[2015-03-16 14:04:56 +09:00]] 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=276813>
- [104] [CITE[Issue 4527 - chromium - implement RFC 2817: Upgrading to TLS Within HTTP/1.1 - An open-source project to help move the web forward. - Google Project Hosting]] ([TIME[2015-03-16 14:07:04 +09:00]] 版) <https://code.google.com/p/chromium/issues/detail?id=4527>
- [102] [CITE[Upgrading to TLS(RFC2817)の設定をApache2.2にしてみる|でびぞー徒然日記]] ([TIME[2015-03-16 14:00:07 +09:00]] 版) <http://debz-di.kabocha.to/archives/2007/06/20070616212947.html>
]REFS]
** RFC 2818
[41] 古く使われてきた [[SSL]] ([[TLS]]) 上で [[HTTP]] を使う方式は、 [[RFC 2818]]
として標準化されました。
[42] その後 [[RFC 2818]] は [[RFC 5785]] と [[RFC 7230]] により[[更新]]されています。
いずれも [CODE(URI)@en[[[https:]]]] [[URL]] について規定するものです。
このため [[RFC 2818]] における [[URL]] に関する規定は現在失効していると解釈されています。
[105] なお [[RFC 2818]] は[[情報提供RFC]]であり、[[IETF]] [[標準化過程]]にはありません。
このため [[RFC 2818]] は標準ではない、従う必要はないなどと主張する人も稀にいます。
[[IETF]] における手続きのみを重視する立場からは間違った主張ではありませんが、
実態としておおむね [[RFC 2818]] に沿った [[HTTPS]] が極めて普及している現実を無視することに意味があるとは思えません。
** RFC 723x
[151] [[RFC 2818]] は [[HTTP/1.1]] の改訂版である [[RFC 723x]] により[[更新]]されていますが、
これは [CODE(URI)@en[[[https:]]]] [[URL]] の定義に関するものです。
それ以外の点は [[RFC 2818]] が参照されています。
** RFC 7540
[148] [[RFC 7540]] は、 [[HTTP/2]] における [[TLS]] の利用について規定しています。
[149] ただ [[TLS]] の [[cipher suite]] や [[TLS拡張]]などに関する規定はありますが、
通常の下位層輸送路としての [[TLS]] の利用方法の規定はありません。
接続の切断時の扱いなどにはまったく言及がありません。
[150] [[service identity]] の検証については、 [[RFC 2818]] を参照しています。
他の規定について言及はまったくありませんが、 [[HTTPS]] としての歴史的継続性から推測すると、
基本的には [[RFC 2818]] の規定に従い動作するべきと思われます。
* メモ
[10] [CITE@en[Official Google Webmaster Central Blog: HTTPS as a ranking signal]]
( ([TIME[2014-08-08 08:15:49 +09:00]] 版))
<http://googlewebmastercentral.blogspot.jp/2014/08/https-as-ranking-signal.html>
[11] [CITE[HTTPS Everywhere | Electronic Frontier Foundation]]
( ([TIME[2014-09-01 09:47:53 +09:00]] 版))
<https://www.eff.org/https-everywhere>
[12] [CITE[Indicators for high-security features - Google グループ]]
( ([TIME[2014-09-18 04:41:11 +09:00]] 版))
<https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/RnAx-t-wOVU/dYjKJF4E7L8J>
[32] [CITE@en[Transitioning the Web to HTTPS]]
( ([TIME[2014-12-09 14:36:23 +09:00]] 版))
<https://w3ctag.github.io/web-https/>
[33] [CITE@en[Official Gmail Blog: Staying at the forefront of email security and reliability: HTTPS-only and 99.978% availability]]
( ([TIME[2014-12-19 08:00:09 +09:00]] 版))
<http://gmailblog.blogspot.jp/2014/03/staying-at-forefront-of-email-security.html>
[34] [CITE@en[Securing the Web]]
([TIME[2015-01-23 09:35:25 +09:00]] 版)
<http://www.w3.org/2001/tag/doc/web-https>
[35] [CITE@en[Follow-up to TAG meeting on Powerful Features]]
([[Wendy Seltzer]] 著, [TIME[2015-02-17 02:07:15 +09:00]] 版)
<https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0298.html>
[36] [CITE@en[Renaming 'powerful features' to 'privileged contexts'. · ee4f1d8 · w3c/webappsec]]
([TIME[2015-02-24 12:52:04 +09:00]] 版)
<https://github.com/w3c/webappsec/commit/ee4f1d83de5fbb720541a440c07f44ececdc98a6>
[37] [CITE[Intent to deprecate: Insecure usage of powerful features - Google グループ]]
([TIME[2015-02-28 11:14:32 +09:00]] 版)
<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2LXKVWYkOus>
[38] [CITE[IRC logs: freenode / #whatwg / 20150227]]
([TIME[2015-02-28 11:18:00 +09:00]] 版)
<http://krijnhoetmer.nl/irc-logs/whatwg/20150227>
[82] [CITE[''''''[''''''ruby-dev:25254'''''']'''''' Re: net/https.rb and server identity (RFC2818)]]
([TIME[2015-03-16 12:49:45 +09:00]] 版)
<http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/25254>
[84] [CITE@en[Bug 393385 – RFC 2818 hostname verification for outgoing HTTPS connections]]
([TIME[2015-03-16 12:51:59 +09:00]] 版)
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=393385>
[85] [CITE[Curl: Re: ''''''[''''''curl'''''']'''''' Adding RFC2818 compliance to axTLS and moving helper functions to a generic place. (#46)]]
([[Daniel Stenberg (daniel_at_haxx.se)]] 著, [TIME[2012-11-06 07:42:29 +09:00]] 版)
<http://curl.haxx.se/mail/lib-2012-11/0048.html>
[108] [CITE@en[Securing the Web]]
([TIME[2015-01-27 14:26:10 +09:00]] 版)
<https://w3ctag.github.io/web-https/>
[109] [CITE@en[w3ctag/web-https]]
([TIME[2015-03-19 16:03:12 +09:00]] 版)
<https://github.com/w3ctag/web-https>
[FIG(quote)[
[FIGCAPTION[
[120] [CITE@en[RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]]
([TIME[2015-02-22 15:44:10 +09:00]] 版)
<http://tools.ietf.org/html/rfc5280#page-104>
]FIGCAPTION]
> CAs SHOULD NOT include URIs that specify https, ldaps, or similar
> schemes in extensions. CAs that include an https URI in one of these
> extensions MUST ensure that the server's certificate can be validated
> without using the information that is pointed to by the URI. Relying
> parties that choose to validate the server's certificate when
> obtaining information pointed to by an https URI in the
> cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess
> extensions MUST be prepared for the possibility that this will result
> in unbounded recursion.
>
]FIG]
[123] [CITE[Part2 - browsersec - Browser Security Handbook, part 2 - Browser Security Handbook - Google Project Hosting]]
([TIME[2015-03-31 16:49:49 +09:00]] 版)
<https://code.google.com/p/browsersec/wiki/Part2#Protocol-level_encryption_facilities>
[55] [CITE@en[Official Google Webmaster Central Blog: HTTPS as a ranking signal]]
([TIME[2015-04-01 01:09:39 +09:00]] 版)
<http://googlewebmastercentral.blogspot.jp/2014/08/https-as-ranking-signal.html>
[59] [CITE[Insecure HTTP Deprecation Plan - Google ドキュメント]]
([TIME[2015-04-14 12:28:53 +09:00]] 版)
<https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit>
[60] [CITE@en[Re: ''''''[''''''EME'''''']'''''' HTTPS performance experiments for large scale content distribution]]
([[Mark Watson]] 著, [TIME[2015-04-16 05:21:43 +09:00]] 版)
<https://lists.w3.org/Archives/Public/www-tag/2015Apr/0027.html>
[62] [CITE@en[Privileged Contexts]]
([TIME[2015-04-24 19:29:37 +09:00]] 版)
<http://www.w3.org/TR/2015/WD-powerful-features-20150424/>
[63] [CITE[Insecure HTTP Deprecation Plan - Google ドキュメント]]
([TIME[2015-05-03 15:22:03 +09:00]] 版)
<https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit>
[67] [CITE@en-US[Deprecating Non-Secure HTTP | Mozilla Security Blog]]
([TIME[2015-05-03 15:25:02 +09:00]] 版)
<https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/>
[69] [CITE[Adopting Encryption: The Need for HTTPS - IABlog]]
([TIME[2015-03-27 23:28:21 +09:00]] 版)
<http://www.iab.net/iablog/2015/03/adopting-encryption-the-need-for-https.html>
[70] [CITE[The HTTPS-Only Standard]]
([TIME[2015-04-29 15:57:01 +09:00]] 版)
<https://https.cio.gov/>
[71] [CITE[Deprecating Non-Secure HTTP Frequently Asked Questions]]
([TIME[2015-05-02 11:35:50 +09:00]] 版)
<https://blog.mozilla.org/security/files/2015/05/HTTPS-FAQ.pdf>
[72] [CITE@ja[HTTPS 化する Web をどう考えるか - Block Rockin’ Codes]]
([TIME[2015-05-06 08:37:43 +09:00]] 版)
<http://jxck.hatenablog.com/entry/web-over-https>
[79] [CITE@en[Please rename while we can · w3c/webappsec@42e9a78]]
([TIME[2015-05-11 11:26:09 +09:00]] 版)
<https://github.com/w3c/webappsec/commit/42e9a78198ba61e630c9b0c7da0ebf39727ee29f>
[106] [CITE@en[Secure Contexts]] ([TIME[2015-05-17 18:30:14 +09:00]] 版) <https://w3c.github.io/webappsec/specs/powerfulfeatures/>
[168] [CITE[Issue 4527 - chromium - implement RFC 2817: Upgrading to TLS Within HTTP/1.1 - An open-source project to help move the web forward. - Google Project Hosting]]
([TIME[2015-06-21 13:46:56 +09:00]] 版)
<https://code.google.com/p/chromium/issues/detail?id=4527>
[169] [CITE[SSL/TLS upgrades - RFC2817 - Google グループ]]
([TIME[2015-06-21 13:53:12 +09:00]] 版)
<https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/4Im0YcJcWiU>
[FIG(quote)[
[FIGCAPTION[
[170] [CITE[エクスプレス予約 新幹線の会員制ネット予約]]
([TIME[2015-07-31 17:59:42 +09:00]] 版)
<http://expy.jp/renew2015/>
]FIGCAPTION]
>
> 8月29日以降は、専用線方式からSSL(暗号化通信)によるインターネット接続方式に変更します。
> これに伴い、リニューアル後は携帯電話の予約画面URLが、「https」から始まるURLへ変更になり、一部の携帯電話(SSL非対応機種)でご利用いただけなくなります。
]FIG]
[181] [CITE@en[1132357 – remove h2-draft support starting in gecko-40]]
([TIME[2015-09-27 00:09:25 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=1132357>
[182] [CITE@en[Bug 468106 – cannot establish an http2 connection]]
([TIME[2015-09-27 00:53:40 +09:00]] 版)
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=468106>
[189] [CITE@en-US[Deprecating Non-Secure HTTP | Mozilla Security Blog]]
([TIME[2015-10-13 19:07:43 +09:00]] 版)
<https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/>
[190] ([TIME[2015-05-02 11:35:50 +09:00]] 版)
<https://blog.mozilla.org/security/files/2015/05/HTTPS-FAQ.pdf>
[191] [CITE@en[Moving t.co to HTTPS only for new links - Announcements - Twitter Developers]]
([[]] 著, [TIME[2015-10-22 20:50:00 +09:00]] 版)
<https://twittercommunity.com/t/moving-t-co-to-https-only-for-new-links/52380>
[192] [CITE@en[Re: Marking HTTP As Non-Secure]]
([[Chris Palmer]] 著, [TIME[2015-11-06 05:05:07 +09:00]] 版)
<https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0001.html>
[193] [CITE[Marking HTTP As Non-Secure - The Chromium Projects]]
([TIME[2015-11-06 07:31:43 +09:00]] 版)
<https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure>
[194] [CITE[TLS Everywhere, not https: URIs - Design Issues]]
([TIME[2015-03-28 06:20:30 +09:00]] 版)
<http://www.w3.org/DesignIssues/Security-NotTheS.html>
[195] [CITE@ja[Google ウェブマスター向け公式ブログ: HTTPS ページが優先的にインデックスに登録されるようになります]]
([TIME[2015-12-18 17:31:34 +09:00]] 版)
<http://googlewebmastercentral-ja.blogspot.jp/2015/12/indexing-https-pages-by-default.html>
[196] [CITE@en-US[Supporting HTTPS and HSTS on w3.org | W3C Blog]]
( ([TIME[2016-01-12 11:13:23 +09:00]] 版))
<https://www.w3.org/blog/2016/01/w3-org-supporting-https-and-hsts/>
[197] [CITE@ja[DevTools へのセキュリティ パネル導入について - Google Developers Japan]]
([TIME[2016-02-23 10:16:43 +09:00]] 版)
<http://googledevjp.blogspot.jp/2016/02/draft-devtools.html>
[199] [CITE@en[Fix #222: no credentials, no TLS client certificate · whatwg/fetch@bef06e1]]
([TIME[2016-03-15 11:37:07 +09:00]] 版)
<https://github.com/whatwg/fetch/commit/bef06e11e3b3b7589d23c0c892057c5cd5174c2a>
[202] [CITE@en[Issue 4527 - chromium - implement RFC 2817: Upgrading to TLS Within HTTP/1.1 - Monorail]]
([TIME[2016-04-18 17:25:26 +09:00]] 版)
<https://bugs.chromium.org/p/chromium/issues/detail?id=4527>
[208] [CITE@ja[WordPress.com、独自ドメインも全てHTTPS接続に - ITmedia エンタープライズ]]
( ([TIME[2016-05-11 01:13:46 +09:00]]))
<http://www.itmedia.co.jp/enterprise/articles/1604/12/news059.html>
[209] [CITE@ja[萩原栄幸の情報セキュリティ相談室:銀行に期待した「常時SSL」 その後…… (1/2) - ITmedia エンタープライズ]]
( ([TIME[2016-05-11 01:19:07 +09:00]]))
<http://www.itmedia.co.jp/enterprise/articles/1502/20/news038.html>
[212] [CITE@en[660749 – (CVE-2011-0082) Firefox doesn't (re)validate certificates when loading a HTTPS page from the cache]]
( ([TIME[2016-06-12 00:04:49 +09:00]]))
<https://bugzilla.mozilla.org/show_bug.cgi?id=660749>
[FIG(quote)[
[FIGCAPTION[
[213] [CITE@en[RFC 7030 - Enrollment over Secure Transport]]
([TIME[2016-06-19 16:27:56 +09:00]])
<https://tools.ietf.org/html/rfc7030#section-3.2.3>
]FIGCAPTION]
> HTTP Basic and Digest authentication MUST only be performed over TLS
> 1.1 '''['''RFC4346''']''' or later versions. NULL and anon cipher suites MUST
> NOT be used because they do not provide confidentiality or support
> mutual certificate-based or certificate-less authentication,
> respectively.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[214] [CITE@en[RFC 7030 - Enrollment over Secure Transport]]
([TIME[2016-06-19 16:27:56 +09:00]])
<https://tools.ietf.org/html/rfc7030#section-3.3>
]FIGCAPTION]
> HTTPS '''['''RFC2818''']''' specifies how HTTP messages are carried over TLS.
> HTTPS MUST be used. TLS 1.1 '''['''RFC4346''']''' (or a later version) MUST be
> used for all EST communications. TLS session resumption '''['''RFC5077''']'''