1041

TLS / SSL (HTTPS) සංකේතනය භාවිතා කරන විට සියලුම URL සංකේතනය කර තිබේද? TLS / SSL (HTTPS) භාවිතා කරන විට සියලුම URL දත්ත සැඟවීමට අවශ්‍ය නිසා මම දැන ගැනීමට කැමැත්තෙමි.

ටීඑල්එස් / එස්එස්එල් ඔබට සම්පූර්ණ URL සංකේතනය ලබා දෙන්නේ නම්, පසුව URL වලින් රහස්‍ය තොරතුරු සැඟවීම ගැන මට කරදර විය යුතු නැත.

ssl https httprequest

— ඩැනියෙල් කිවාටිනෝස්
source

78

කෙසේ හෝ රහස්‍ය දත්ත URL ය තුළ තැබීම නරක අදහසකි. එය බ්‍රව්සරයේ ලිපිනයෙහි ද නරක ලෙස පෙන්වනු ඇත, මතකද? ඔවුන්ගේ මුරපදය තිරය දෙස බැලූ ඕනෑම කෙනෙකුට දැකිය හැකි නම් මිනිසුන් එයට කැමති නැත. රහස්‍ය දත්ත URL ය තුළ තැබිය යුතු යැයි ඔබ සිතන්නේ ඇයි?

— jalf

44

URL යන් බ්‍රව්සර් ඉතිහාසයේ සහ සේවාදායක ලොග් වලද ගබඩා කර ඇත - මගේ නම සහ මුරපදය කොතැනක හෝ ගබඩා කර තබා ගැනීමට මට අවශ්‍ය නම්, එය මෙම ස්ථාන දෙකෙහි නොවනු ඇත.

— පිස්ක්වෝර්

49

උදාහරණයක් ලෙස, මම සංචාරය කරනවා යැයි සිතමු https://somewhere_i_trust/ways_to_protest_against_the_government/. එවිට URL හි රහස්‍ය දත්ත අඩංගු වේ, එනම් මගේ රජයට එරෙහිව විරෝධය දැක්වීමට මා සලකා බලන යෝජනාවයි.

— ස්ටීව් ජෙසොප්

43

ස්වදේශීය (බ්‍රව්සර් මත පදනම් නොවන) යෙදුමකින් HTTP ඉල්ලීමක් කරන විට මම මෙම ප්‍රශ්නය මගෙන්ම ඇසුවෙමි. මම හිතන්නේ මෙය ජංගම යෙදුම් සංවර්ධකයින්ට උනන්දු විය හැකිය. මෙම අවස්ථාවේ දී, ඉහත අදහස් (සත්‍ය වුවත්) අදාල නොවේ (යූආර්එල් නොපෙනේ, ගවේෂණ ඉතිහාසයක් නැත), පිළිතුර ලබා දෙමින්, මගේ අවබෝධයට සරල ය: "ඔව්, එය සංකේතනය කර ඇත".

— ඩැනීඒ

24

ඔබ වරක් HTTPS යැයි සිතන අය සඳහා ඔබ යන්නේ කොහේදැයි කිසිවෙකු දන්නේ නැත, මෙය පළමුව කියවන්න: සේවාදායකයේ ධාරක නාමය (උදා: example.com) තවමත් SNI නිසා කාන්දු වේ . මෙය ඩීඑන්එස් සමඟ කිසිසේත්ම සම්බන්ධ නැති අතර ඔබ ඩීඑන්එස් භාවිතා නොකළත් හෝ සංකේතාත්මක ඩීඑන්එස් භාවිතා නොකළත් කාන්දුව සිදුවනු ඇත.

— පැසීරියර්

929

ඔව්, SSL සම්බන්ධතාවය TCP ස්තරය සහ HTTP ස්තරය අතර වේ. සේවාදායකයා සහ සේවාදායකයා පළමුව ආරක්ෂිත සංකේතාත්මක TCP සම්බන්ධතාවයක් (SSL / TLS ප්‍රොටෝකෝලය හරහා) ස්ථාපිත කරන අතර පසුව සේවාදායකයා එම සංකේතාත්මක TCP සම්බන්ධතාවය හරහා HTTP ඉල්ලීම (GET, POST, DELETE ...) යවනු ඇත.

— මාක් නොවාකොව්ස්කි
source

100

ප්‍රශ්නය පිළිබඳව අදහස් දැක්වීමේදී @ ජල්ෆ් සඳහන් කළ කාරණය තවමත් සඳහන් කිරීම වටී. බ්‍රව්සරයේ ඉතිහාසය තුළ URL දත්ත සුරැකෙනු ඇත, එය දිගු කාලීනව අනාරක්ෂිත විය හැකිය.

— මයිකල් එක්ස්ට්‍රෑන්ඩ්

21

GET හෝ POST පමණක් නොවේ. DELETE, PUT, HEAD, හෝ TRACE විය හැකිය.

4

ඔව් එය බ්‍රව්සරයේ ඉතිහාසය සඳහා ආරක්ෂක ගැටළුවක් විය හැකිය. නමුත් මගේ නඩුවේදී මම බ්‍රව්සරය භාවිතා නොකරමි (මුල් පෝස්ටුවේ බ්‍රව්සරයක් ගැන සඳහන් කර නැත). ස්වදේශීය යෙදුමක තිරය පිටුපස අභිරුචි https ඇමතුමක් භාවිතා කිරීම. ඔබගේ යෙදුමේ වෙන් කිරීමේ සම්බන්ධතාවය ආරක්ෂිත බව සහතික කිරීම සඳහා එය සරල විසඳුමකි.

— සින්ගල්-ඩිංගල්

31

කෙසේ වෙතත්, URL හි DNS විසදුම බොහෝ විට සංකේතනය කර නොමැති බව සලකන්න. එබැවින් ඔබගේ ගමනාගමනය මංකොල්ල කන කෙනෙකුට ඔබ පිවිසීමට උත්සාහ කරන වසම තවමත් දැක ගත හැකිය.

— ChewToy

22

එස්එන්එල් යූඑස්එල් සංකේතාංකනයේ 'ධාරක' කොටස බිඳ දමයි. ඔබට මෙය වයර් ෂාර්ක් මගින් පරීක්ෂා කළ හැකිය. SNI සඳහා තේරීම් කාරකයක් ඇත, නැතහොත් ඔබ දුරස්ථ ධාරකයට සම්බන්ධ වූ විට ඔබේ SSL පැකට් සමාලෝචනය කළ හැකිය.

— cmouse

683

කිසිවෙකු කම්බි අල්ලා ගැනීමක් ලබා දී නැති නිසා, මෙන්න එකක්.
සේවාදායකයේ නම (URL හි වසම් කොටස) ClientHelloපැකට්ටුවේ සරල පා .යෙන් ඉදිරිපත් කෙරේ .

පහත දැක්වෙන්නේ බ්‍රව්සර් ඉල්ලීමක් පහත පරිදි වේ:
https://i.stack.imgur.com/path/?some=parameters&go=here

ටීඑල්එස් අනුවාද ක්ෂේත්‍ර පිළිබඳ වැඩි විස්තර සඳහා මෙම පිළිතුර බලන්න (ඒවායින් 3 ක් ඇත - අනුවාද නොවේ, එක් එක් අනුවාද අංක අඩංගු ක්ෂේත්‍ර!)

Https://www.ietf.org/rfc/rfc3546.txt වෙතින් :

3.1. සේවාදායකයේ නම දර්ශකය

[TLS] සේවාදායකයෙකුට එය සම්බන්ධ වන සේවාදායකයේ නම සේවාදායකයෙකුට පැවසීමට යාන්ත්‍රණයක් සපයන්නේ නැත. තනි යටින් පවතින ජාල ලිපිනයකින් බහු 'අථත්ය' සේවාදායකයන් සත්කාරකත්වය සපයන සේවාදායකයන් වෙත ආරක්ෂිත සම්බන්ධතා සැපයීම සඳහා සේවාදායකයින්ට මෙම තොරතුරු සැපයීම යෝග්ය වේ.

සේවාදායකයේ නම සැපයීම සඳහා, සේවාදායකයින්ට (දීර් extended) සේවාදායක හෙලෝ හි "server_name" වර්ගයේ දිගුවක් ඇතුළත් කළ හැකිය.

කෙටියෙන්:

FQDN (URL එක වසම කොටස) සමහර සම්ප්රේෂණය කළ පැහැදිලි දී ඇතුළත ClientHelloSNI දීර්ඝ භාවිතා කරන්නේ නම් පැකට්
ඉල්ලීම් URL එක HTTP දෙයක් (OSI Layer 7) බැවින් ඉතිරි URL ( /path/?some=parameters&go=here) තුළ කිසිදු ව්‍යාපාරයක් නොමැත ClientHello, එබැවින් එය කිසි විටෙකත් TLS අත් හුවමාරුවක නොපෙන්වයි (4 වන ස්ථරය හෝ 5). ඒක ගැන මත පසුව පැමිණ GET /path/?some=parameters&go=here HTTP/1.1, HTTP ඉල්ලීමක් පසු එම ආරක්ෂිත TLS නාලිකාව ආරම්භ කර ඇත.

විධායක සාරාංශය

වසම් නාමය පැහැදිලිව සම්ප්‍රේෂණය කළ හැකිය (එස්එල්අයි දිගුව ටීඑල්එස් අත් හුවමාරුවේ භාවිතා කරන්නේ නම්) නමුත් URL (මාර්ගය සහ පරාමිතීන්) සෑම විටම සංකේතනය කර ඇත.

මාර්තු 2019 යාවත්කාලීන කිරීම

මෙය ගෙන ඒමට ස්තූතියි carlin.scott .

මෙම කෙටුම්පත RFC යෝජනාව හරහා SNI දිගුවේ ගෙවීම් දැන් සංකේතනය කළ හැකිය . මෙම හැකියාව පවතින්නේ ටීඑල්එස් 1.3 හි පමණි (විකල්පයක් ලෙස එය ක්‍රියාත්මක කිරීම සඳහා එය දෙපැත්තටම වේ) සහ ටීඑල්එස් 1.2 හා ඊට පහළින් පසුගාමී අනුකූලතාවයක් නොමැත.

CloudFlare එය කරන අතර ඔබට මෙහි අභ්‍යන්තරය ගැන වැඩිදුර කියවිය හැකිය - කුකුළු මස් බිත්තරයට පෙර පැමිණිය යුතු නම්, ඔබ කුකුළු මස් තබන්නේ කොහේද?

ප්‍රායෝගිකව මෙයින් අදහස් කරන්නේ FQDN සරල පා text යෙන් සම්ප්‍රේෂණය කරනවා වෙනුවට (වයර්ෂාර්ක් ග්‍රහණ සංදර්ශන වැනි), දැන් එය සංකේතනය කර ඇති බවයි.

සටහන: ප්‍රතිලෝම ඩීඑන්එස් විමසුම මඟින් අපේක්ෂිත ගමනාන්ත ධාරකය කෙසේ හෝ හෙළි කරන බැවින් මෙය ආරක්ෂාවට වඩා රහස්‍යතා පැතිකඩ ආමන්ත්‍රණය කරයි.

— badSnobu
source

39

A සිට Z දක්වා සම්පූර්ණ පැහැදිලි කිරීමක් සහිත පරිපූර්ණ පිළිතුර. විධායක සාරාංශයට මම කැමතියි. මගේ දවස සාදනු ලැබුවේ @evilSnobu

— oscaroscar

4

නියම පිළිතුර, ඉහළට! බ්‍රව්සරයේ ඉතිහාසය කාන්දුවක් විය හැකි බැවින් සේවාදායකයාගේ කොටස සලකා බලන්න. කෙසේ වෙතත්, ප්‍රවාහන ස්ථරය සම්බන්ධයෙන්, URL- පරාමිතීන් සංකේතනය කර ඇත.

— ජෙන්ස් ක්‍රෙඩ්ලර්

2

ටීඑල්එස් 1.3 එස්එන්අයි දිගුව සංකේතනය කර ඇති නිසා ඔබට මෙම පිළිතුර යාවත්කාලීන කිරීමට අවශ්‍ය විය හැකි අතර විශාලතම සීඩීඑන් එක කරන්නේ එයයි : blog.cloudflare.com/encrypted-sni ඇත්ත වශයෙන්ම පැකට් ස්නයිෆර් කෙනෙකුට ප්‍රතිලෝම-ඩීඑන්එස් සෙවීමක් කළ හැකිය ඔබ සම්බන්ධ කරන IP ලිපින.

— carlin.scott

@evilSnobu, නමුත් පරිශීලක නාමය: මුරපදය පරිශීලක නාමයේ කොටස : password@domain.com සංකේතනය කර ඇත, නේද? එබැවින් https භාවිතයෙන් url හි සංවේදී දත්ත යැවීම ආරක්ෂිතයි.

— මැක්සිම් ෂමිහුලව්

1

ඒවා කම්බි මත සංකේතනය කර ඇත (ප්‍රවාහනයේදී) නමුත් අවසානය (පරිශීලකයා හෝ සේවාදායකයා) URL ය සරල පෙළ ගොනුවකට ලොග් කර අක්තපත්‍ර සනීපාරක්ෂාව නොකරන්නේ නම් ... දැන් එය වෙනස් සංවාදයකි.

— badSnobu

163

ලෙස අනෙකුත් පිළිතුරු දැනටමත්, https "URL ලිපින" නියත වශයෙන්ම සටහන් කර ගැනේ අවධාරණය කර තිබේ. කෙසේ වෙතත්, ඩොමේන් නාමය නිරාකරණය කිරීමේදී ඔබගේ DNS ඉල්ලීම / ප්‍රතිචාරය බොහෝ විට නොවිය හැකි අතර ඇත්ත වශයෙන්ම ඔබ බ්‍රව්සරයක් භාවිතා කරන්නේ නම් ඔබේ URL ද පටිගත විය හැකිය.

— Zach Scrivena
source

22

ලබා දී ඇති URL එකක් ඔබගේ ඉතිහාසයේ තිබේද නැද්ද යන්න පරීක්ෂා කිරීමට සම්පුර්ණයෙන්ම සම්බන්ධයක් නැති වෙබ් අඩවියකට ඉඩ දෙන ජාවාස්ක්‍රිප්ට් හක්ස් ඇති බැවින් URL පටිගත කිරීම වැදගත් වේ. දිගු අහඹු නූලක් ඇතුලත් කිරීමෙන් ඔබට යූආර්එල් එකක් හඳුනාගත නොහැකිය, නමුත් එය පොදු යූආර්එල් එකක් නම් ප්‍රහාරකයාට එය නැරඹූ බව පැවසිය හැකි අතර, එහි කෙටි රහසක් තිබේ නම්, ප්‍රහාරකයාට එය තිරිසන් ලෙස බල කළ හැකිය සාධාරණ වේගයකින්.

— ස්ටීව් ජෙසොප්

8

Te ස්ටීව් ජෙසොප්, කරුණාකර “ලබා දී ඇති URL එකක් ඔබේ ඉතිහාසයේ තිබේද නැද්ද යන්න පරීක්ෂා කිරීමට සම්පුර්ණයෙන්ම සම්බන්ධයක් නැති වෙබ් අඩවියකට ඉඩ දෙන ජාවාස්ක්‍රිප්ට් හැක්”

— පැසීරියර්

6

Ac පැකේරියර්: හැක්ස් ඔෆ් පා course මාලාව, නමුත් මම ඒ අවස්ථාවේ කතා කරමින් සිටියේ stackoverflow.com/questions/2394890/… වැනි දේවල් ය . 2010 දී මෙම කරුණු විමර්ශනය කිරීම සහ ප්‍රහාරයන් පිරිපහදු කිරීම විශාල ගනුදෙනුවක් විය, නමුත් මම මේ මොහොතේ එය අනුගමනය නොකරමි.

— ස්ටීව් ජෙසොප්

2

AcPacerier: තවත් උදාහරණ: webdevwonders.com/… , webdevwonders.com/…

— ස්ටීව් ජෙසොප්

1

සංකේතාත්මක DNS සේවාව සමඟ ඔබට OpenDNS භාවිතා කළ හැකිය. මම එය මගේ මැක් මත භාවිතා කරමි, නමුත් වින්ඩෝස් අනුවාදය නිසියාකාරව ක්‍රියාත්මක නොවන බව මට පෙනී ගියේය. එය ටික කලකට පෙර වුවද, දැන් එය හොඳින් ක්‍රියාත්මක වනු ඇත. ලිනක්ස් සඳහා තවමත් කිසිවක් නැත. opendns.com/about/innovations/dnscrypt

— SPRBRN

104

URL ද ඇතුළුව සම්පූර්ණ ඉල්ලීම සහ ප්‍රතිචාරය සංකේතනය කර ඇත.

ඔබ HTTP ප්‍රොක්සියක් භාවිතා කරන විට, එය ඉලක්ක සේවාදායකයේ ලිපිනය (වසම) දන්නා නමුත් මෙම සේවාදායකයේ ඉල්ලූ මාර්ගය නොදන්නා බව සලකන්න (එනම් ඉල්ලීම සහ ප්‍රතිචාරය සැමවිටම සංකේතනය කර ඇත).

— පීටර් ආටිබ්රානි
source

1

ඉල්ලීමේ සම්පූර්ණත්වය. ධාරක නාමය පැහැදිලිව යවනු ලැබේ. අනෙක් සියල්ල සංකේතනය කර ඇත.

— සෑම් සිරි

99

පෙර පිළිතුරු සමඟ මම එකඟ වෙමි:

පැහැදිලිව කිවහොත්:

ටීඑල්එස් සමඟ, URL යේ පළමු කොටස ( https://www.example.com/ ) සම්බන්ධතාවය ගොඩනඟන විට එය තවමත් දැකිය හැකිය. දෙවන කොටස (/ herearemygetparameters / 1/2/3/4) TLS විසින් ආරක්ෂා කර ඇත.

කෙසේ වෙතත් ඔබ GET ඉල්ලීමෙහි පරාමිතීන් නොතැබීමට හේතු ගණනාවක් තිබේ.

පළමුව, දැනටමත් වෙනත් අය සඳහන් කර ඇති පරිදි: - බ්‍රව්සර් ලිපින තීරුව හරහා කාන්දු වීම - ඉතිහාසය හරහා කාන්දු වීම

ඊට අමතරව ඔබට http යොමුකරු හරහා URL කාන්දු වී ඇත: පරිශීලකයා TLS හි A වෙබ් අඩවිය දකී, පසුව B අඩවියට සබැඳියක් ක්ලික් කරන්න. අඩවි දෙකම TLS හි තිබේ නම්, B අඩවි සඳහා වන ඉල්ලීම A වෙබ් අඩවියෙන් සම්පූර්ණ URL එක අඩංගු වේ ඉල්ලීමේ යොමු පරාමිතිය. B වෙබ් අඩවියේ පරිපාලක විසින් එය සේවාදායක B හි ලොග් ලිපිගොනු වලින් ලබා ගත හැක.)

— ටොබියාස්
source

3

ටොබියාස් කියන්නේ කුමක්දැයි ඔබට තේරුණේ නැත. ඔහු කියන්නේ ඔබ A වෙබ් අඩවියේ සබැඳියක් ක්ලික් කළහොත් එය ඔබව B අඩවියට ගෙන යනු ඇති බවයි, එවිට B වෙබ් අඩවිය යොමු යොමු URL ලබා ගනී. උදාහරණයක් ලෙස, ඔබ siteA.com?u=username&pw=123123 හි සිටී නම්, siteB.com (එය siteA.com පිටුවට සම්බන්ධ කර ඇත) වෙත යොමු කිරීමක් ලෙස " siteA.com?u=username&pw=123123 " ලැබෙනු ඇත. URL, බ්‍රව්සරය මඟින් HTTPS තුළ siteB.com වෙත යවන ලදි. මෙය සත්‍ය නම් එය ඉතා නරක ය. මෙය සැබෑ ටොබියාස් ද?

— trusktr

9

JEJP, සියලුම නවීන වෙබ් බ්‍රව්සර් භාවිතා කරන SNI නිසා වසම දෘශ්‍යමාන වේ. ඔබ පිවිසෙන වෙබ් අඩවියේ වසම ඕනෑම කෙනෙකුට දැකිය හැකි බව පෙන්වන ඊඑෆ්එෆ් වෙතින් මෙම රූප සටහන බලන්න . මෙය බ්‍රව්සර් දෘශ්‍යතාව ගැන නොවේ. එය කන් ඇසෙන අයට පෙනෙන දේ ගැන ය.

— Buge

10

ustrusktr: බ්‍රව්සර් විසින් HTTPS පිටු වලින් යොමු කිරීමේ ශීර්ෂයක් යැවිය යුතු නොවේ. මෙය HTTP පිරිවිතරයේ කොටසකි .

— මාටින් ගයිස්ලර්

8

Ar මාර්ටින්ගයිස්ලර්, මූල පදය “කළ යුතු” යන්නයි. බ්‍රව්සර් "කළ යුතු දේ" ගැන එතරම් තැකීමක් නොකරයි ("අනිවාර්යයෙන්ම" යන්නට වෙනස්ව). ඔබේම සබැඳියෙන්: "පරිශීලකයාට යොමු කිරීමේ ක්ෂේත්‍රය යවා තිබේද නැද්ද යන්න තෝරා ගැනීමට තරයේ නිර්දේශ කර ඇත. නිදසුනක් ලෙස, බ්‍රව්සර් සේවාදායකයෙකුට විවෘතව / නිර්නාමිකව බ්‍රවුස් කිරීම සඳහා ටොගල් ස්විචයක් තිබිය හැකි අතර එමඟින් පිළිවෙලින් යැවීම සක්‍රීය / අක්‍රීය කළ හැකිය. යොමුකරු සහ තොරතුරු වලින් " . ඕප්ස්, එය හරියටම ක්‍රෝම් කළ දෙයයි. ඔබ නොපැහැදිලි මාදිලියේ සිටියද ක්‍රෝම් යොමු කරන්නා කාන්දු වීම හැර .

— පැසීරියර්

48

මාක් නොවාකොව්ස්කිගේ ප්‍රයෝජනවත් පිළිතුරට අමතරව - URL ය සේවාදායකයේ ඇති ලොග් වල ගබඩා කර ඇත (උදා: / etc / httpd / log / ssl_access_log), එබැවින් සේවාදායකයාට වැඩි කාලයක් තොරතුරු පවත්වා ගැනීමට ඔබට අවශ්‍ය නැතිනම් පදය, එය URL එකට දමන්න එපා.

— රොද්රි කුසාක්
source

39

ඔව් සහ නැත.

සම්බන්ධතාවය සැකසීමට භාවිතා කරන බැවින් සේවාදායක ලිපින කොටස සංකේතනය කර නොමැත.

සංකේතාත්මක SNI සහ DNS සමඟ මෙය අනාගතයේදී වෙනස් විය හැකි නමුත් 2018 වන විට තාක්ෂණයන් දෙකම බහුලව භාවිතා නොවේ.

මාර්ගය, විමසුම් නූල් ආදිය සංකේතනය කර ඇත.

GET ඉල්ලීම් සඳහා සටහන පරිශීලකයාට ස්ථාන තීරුවෙන් පිටත URL එක කපා ඇලවිය හැකි අතර තිරය දෙස බලන ඕනෑම කෙනෙකුට දැකිය හැකි රහස්‍ය තොරතුරු එහි තැබීමට ඔබට අවශ්‍ය නොවනු ඇත.

— සබන් බොක්ස්
source

8

මෙය +1 කිරීමට කැමති නමුත් මම "ඔව් සහ නැත" නොමඟ යවන සුළු දෙයක් ලෙස සලකමි - සංකේතාංකනයකින් තොරව DNS භාවිතයෙන් සේවාදායකයේ නම විසඳනු ඇති බව පෙන්වා දීමට ඔබ එය වෙනස් කළ යුතුය.

— ලෝරන්ස් ඩොල්

7

මගේ අවබෝධය අනුව, OP යූආර්එල් යන වචනය නිවැරදි අර්ථයෙන් භාවිතා කරයි. මෙම පිළිතුර වඩාත් නොමඟ යවන සුළු යැයි මම සිතමි, එය URL හි ධාරක නාමය සහ DNS විභේදනයේ ධාරක නාමය අතර වෙනස පැහැදිලිව නොදක්වයි.

— ගුයිලූම්

4

URL සංකේතනය කර ඇත. HTTP ගනුදෙනුවේ සෑම අංශයක්ම සංකේතනය කර ඇත. 'අනෙක් සියල්ල' පමණක් නොවේ. කාලය. -1.

— මාර්ක්විස් ඔෆ් ලෝර්න්

4

JEJP නමුත් DNS විමසුම මඟින් URL හි එක් අවස්ථාවක ඇති දේ භාවිතා කරයි, එබැවින් තාක්ෂණික නොවන පුද්ගලයාට මුළු URL එකම සංකේතනය කර නොමැත. තාක්‍ෂණික නොවන දේ සොයා බැලීමට හුදෙක් ගූගල්.කොම් භාවිතා කරන තාක්‍ෂණික නොවන පුද්ගලයා දත්ත අවසානයේ වාසය කරන්නේ කොතැනද යන්න හෝ එය හසුරුවන්නේ කෙසේදැයි නොදනී. පරිශීලකයා පිවිසෙන URL හි කොටසක් වන වසම 100% සංකේතනය කර නැත, මන්ද ප්‍රහාරකයා ලෙස මට ඔහු පිවිසෙන්නේ කුමන වෙබ් අඩවියටද යන්න දැනගත හැකිය. ගිහියාට සහජයෙන්ම සංකේතනය කර ඇත්තේ URL එකක / මාර්ගය පමණි (එය කෙසේ වෙතත් එය වැදගත් නොවේ).

— trusktr

6

@ ඊ.ජේ.පී., us ට්‍රස්ක්ටර්, @ ලෝරන්ස්, @ ගුයිලූම්. ඔබ සියල්ලන්ම වැරදී ඇත. මෙයට ඩීඑන්එස් සමඟ කිසිදු සම්බන්ධයක් නැත. එස්එන්අයි " ටීඑල්එස් සාකච්ඡාවේ කොටසක් ලෙස අථත්ය වසමේ නම යවන්න ", එබැවින් ඔබ ඩීඑන්එස් භාවිතා නොකලත් හෝ ඔබේ ඩීඑන්එස් සංකේතනය කර තිබුණත්, ස්නයිෆර්වරයෙකුට ඔබගේ ඉල්ලීම්වල සත්කාරක නාමය තවමත් දැකිය හැකිය .

— පැසීරියර්

9

ගමනාගමනය අධීක්‍ෂණය කරන තෙවන පාර්ශවයකට ඔබේ ගමනාගමනය පරීක්ෂා කිරීමෙන් වෙබ් අඩවියට පිවිසෙන විට වෙනත් පරිශීලකයෙකුගේ ගමනාගමනය හා සැසඳීමෙන් එය පරීක්ෂා කළ හැකිය. උදාහරණයක් ලෙස වෙබ් අඩවියක පිටු 2 ක් තිබුනේ නම්, එකක් අනෙකට වඩා විශාල නම්, දත්ත හුවමාරුවේ ප්‍රමාණය සංසන්දනය කිරීමෙන් ඔබ ගිය පිටුව කුමක්දැයි කියනු ඇත. මෙය තෙවන පාර්ශවයෙන් සැඟවිය හැකි ක්‍රම තිබේ නමුත් ඒවා සාමාන්‍ය සේවාදායකයක් හෝ බ්‍රව්සර් හැසිරීමක් නොවේ. SciRate, https://scirate.com/arxiv/1403.0297 වෙතින් මෙම ලිපිය බලන්න .

පොදුවේ ගත් කල වෙනත් පිළිතුරු නිවැරදි ය, ප්‍රායෝගිකව මෙම පත්‍රිකාව මඟින් සංචාරය කළ පිටු (එනම් URL) තරමක් .ලදායී ලෙස තීරණය කළ හැකි බව පෙන්නුම් කරයි.

— pbhj
source

එය සැබවින්ම කළ හැකි වන්නේ ඉතා කුඩා වෙබ් අඩවි වල පමණක් වන අතර, එවැනි අවස්ථාවන්හිදී, වෙබ් අඩවියේ තේමාව / ස්වරය / ස්වභාවය සෑම පිටුවකම එක හා සමාන වේ.

— කැමරන්

5

මා විසින් උපුටා දැක්වීමේදී: "සෞඛ්‍ය සේවා, මූල්‍ය, නීති සේවා සහ ප්‍රවාහ වීඩියෝ වැනි ක්ෂේත්‍රවල පුළුල් ලෙස භාවිතා වන, කර්මාන්තයේ ප්‍රමුඛ වෙබ් අඩවි 10 ක HTTPS යෙදවීම පුරා පැතිරී ඇති වෙබ් පිටු 6000 කට අධික සංඛ්‍යාවක් වෙත රථවාහන විශ්ලේෂණ ප්‍රහාරයක් අපි ඉදිරිපත් කරමු. අපගේ ප්‍රහාරය තනි පිටු හඳුනා ගනී 89% නිරවද්‍යතාවයකින් යුත් එකම වෙබ් අඩවිය [...] ". ශක්‍යතාව පිළිබඳ ඔබේ නිගමනය වැරදියි.

— pbhj

2

මෙවැනි අවදානමක් ගැන වැඩිදුර කියවීමට උනන්දුවක් දක්වන ඕනෑම කෙනෙකුට, මෙම ආකාරයේ ප්‍රහාර සාමාන්‍යයෙන් හැඳින්වෙන්නේ පැති නාලිකා ප්‍රහාර ලෙස ය .

— ඩෑන් බෙචර්ඩ්

8

එය දැන් 2019 වන අතර TLS v1.3 නිකුත් කර ඇත. Cloudflare ට අනුව, TLS v1.3 ට ස්තූතිවන්ත වෙමින් සේවාදායකයේ නම දර්ශකය (SNI හෝ ධාරක නාමය) සංකේතනය කළ හැකිය. ඉතින්, මම මටම කියා ගත්තා! Cloudflare.com හි TCP පැකට් තුළ එය පෙනෙන්නේ කෙසේදැයි බලමු. එබැවින්, ගූගල් ක්‍රෝම් බ්‍රව්සරයක් ලෙස සහ වයර්ෂාර්ක් පැකට් ස්නයිෆර් ලෙස භාවිතා කරමින් ක්ලවුඩ්ෆ්ලේර් සේවාදායකයේ ප්‍රතිචාරයෙන් මම “ග්‍රාහක හෙලෝ” අත් සේදීමේ පැකට්ටුවක් අල්ලා ගතිමි. ඔබට පහත දැක්වෙන පරිදි සේවාදායක හෙලෝ පැකට්ටුව තුළ මට තවමත් ධාරක නාමය සරල පා text යෙන් කියවිය හැකිය. එය සංකේතනය කර නැත.

එබැවින් මෙය තවමත් නිර්නාමික සම්බන්ධතාවයක් නොවන බැවින් ඔබට කියවිය හැකි දේ ගැන පරිස්සම් වන්න. සේවාදායකයා සහ සේවාදායකයා අතර ඇති මිඩ්ල්වෙයාර් යෙදුමකට සේවාදායකයකු ඉල්ලා සිටින සෑම වසමක්ම ලොග් කළ හැකිය.

එබැවින්, SNI සංකේතනය සඳහා TLSv1.3 සමඟ වැඩ කිරීමට අමතර ක්‍රියාත්මක කිරීම් අවශ්‍ය බව පෙනේ

2020 ජුනි යාවත්කාලීන කරන්න: සංකේතාත්මක SNI බ්‍රව්සරය විසින් ආරම්භ කරන ලද බවක් පෙනේ. ඔබගේ බ්‍රව්සරය සංකේතාත්මක SNI සඳහා සහය දක්වයිදැයි පරීක්ෂා කිරීමට ඔබට Cloudflare පිටුවක් ඇත:

https://www.cloudflare.com/ssl/encrypted-sni/

මෙම අවස්ථාවේදී, මම සිතන්නේ ගූගල් ක්‍රෝම් එයට සහාය නොදක්වයි. ඔබට ෆයර්ෆොක්ස් හි ගුප්තකේතනය කළ එස්එන්අයි අතින් ක්‍රියාත්මක කළ හැකිය. කිසියම් හේතුවක් නිසා මම එය උත්සාහ කළ විට එය ක්ෂණිකව ක්‍රියාත්මක වූයේ නැත. ෆයර්ෆොක්ස් වැඩ කිරීමට පෙර මම එය දෙවරක් නැවත ආරම්භ කළෙමි:

URL ක්ෂේත්‍රය තුළ: about: config ටයිප් කරන්න.

Network.security.esni.enabled සත්‍ය දැයි පරීක්ෂා කරන්න. ඔබගේ හැඹිලිය ඉවත් කරන්න / නැවත ආරම්භ කරන්න

වෙබ් අඩවියට යන්න, මම කලින් සඳහන් කළා.

ඔබට පෙනෙන පරිදි කෝපි හල් හිමිකරුවෙකු මිනිසුන් පිවිසෙන වෙබ් අඩවි ලැයිස්තුවට ලොග් නොවන බවට සහතික වීමට අවශ්‍ය අයට VPN සේවාවන් අදටත් ප්‍රයෝජනවත් වේ.

— නිකොලස් ගුරිනෙට්
source

"SNI සංකේතනය කළ හැකිය" - එය ප්‍රධාන කරුණයි. වත්මන් ගූගල් ක්‍රෝම් සමඟ cloudflare.com/ssl/encrypted-sni පරික්ෂා කිරීමෙන් "මෙම පිටුවට පිවිසෙන විට ඔබගේ බ්‍රව්සරය SNI සංකේතනය කර නැත" යනුවෙන් පවසයි. ටැන්ගෝ සඳහා දෙකක් ගත වේ ...

— පිස්ක්වෝර් ගොඩනැගිල්ලෙන් පිටව ගියේ

2

පෙනෙන විදිහට වත්මන් ෆයර්ෆොක්ස් හට ඊඑස්එන්අයි කළ හැකි නමුත් එය පෙරනිමියෙන් අක්‍රීය කර ඇත: ඔබ සක්‍රීය කළ යුතුය network.security.esni.enabled, network.trr.mode2 ට සකසා ගත යුතුය (එය දැනට ඔබගේ ඩොඑච් විසදුම ක්ලවුඩ් ෆ්ලෙයාර් ලෙස සකසයි), සහ බ්‍රව්සරය නැවත ආරම්භ කරන්න (sic!); එවිට එය වසමේ යටිතල පහසුකම් මඟින් සහාය දක්වන ESNI භාවිතා කරනු ඇත. වැඩි විස්තර සඳහා blog.mozilla.org/security/2018/10/18/… බලන්න.

— පිස්ක්වෝර්

7

ඔබට සැමවිටම සම්පූර්ණ URL හි පෞද්ගලිකත්වය කෙරෙහි විශ්වාසය තැබිය නොහැක. උදාහරණයක් ලෙස, සමහර විට ව්‍යවසාය ජාල වල මෙන්, ඔබේ සමාගම් පරිගණකය වැනි සැපයුම් උපාංග අතිරේක “විශ්වාසදායක” මූල සහතිකයක් සමඟ වින්‍යාස කර ඇති අතර එමඟින් ඔබේ බ්‍රව්සරයට නිහ ly ව https ගමනාගමනය පිළිබඳ ප්‍රොක්සි (මිනිසා අතරමැදි) පරීක්ෂණයක් විශ්වාස කළ හැකිය. . මෙයින් අදහස් කරන්නේ සම්පූර්ණ URL එක පරීක්ෂා කිරීම සඳහා නිරාවරණය වන බවයි. මෙය සාමාන්‍යයෙන් ලොගයකට සුරකිනු ඇත.

තවද, ඔබගේ මුරපද නිරාවරණය වී ඇති අතර බොහෝ විට ලොග් වී ඇති අතර මෙය එක් වරක් මුරපද භාවිතා කිරීමට හෝ ඔබේ මුරපද නිතර වෙනස් කිරීමට තවත් හේතුවකි .

අවසාන වශයෙන්, වෙනත් ආකාරයකින් සංකේතනය කර නොමැති නම් ඉල්ලීම සහ ප්‍රතිචාර අන්තර්ගතය ද නිරාවරණය වේ.

පරීක්ෂණ සැකසුම පිළිබඳ එක් උදාහරණයක් මෙහි චෙක්පොයින්ට් විසින් විස්තර කෙරේ . සපයන ලද පළාත් සභා භාවිතා කරමින් පැරණි විලාසිතාවේ “අන්තර්ජාල කැෆේ” ද මේ ආකාරයෙන් සැකසිය හැකිය.

— දොන් ගිලිස්
source

6

අනුපිටපත් ප්‍රශ්නයක මගේ පිළිතුරට සම්බන්ධ කිරීම . බ්‍රව්සර් ඉතිහාසයේ ඇති URL ය, සේවාදායක පාර්ශව ලොග් වීම පමණක් නොව එය HTTP Referrer ශීර්ෂය ලෙසද යවනු ලැබේ, ඔබ තෙවන පාර්ශවීය අන්තර්ගතයන් භාවිතා කරන්නේ නම්, ඔබගේ පාලනයෙන් පිටත ප්‍රභවයන්ට URL නිරාවරණය කරයි.

— ජොෂ්බර්ක්
source

ඔබගේ තෙවන පාර්ශවීය ඇමතුම් ලබා දීම HTTPS අස්වැන්නක් වුවද මෙය ගැටළුවක් නොවේද?

— ලියම්

3

එය තෙවන පාර්ශවීය සහතිකය සමඟ සංකේතනය කර ඇති බැවින් ඔවුන්ට URL එක දැකගත හැකි වනු ඇත

— ජොෂ්බර්ක්

3

දැනටමත් මෙහි හොඳ පිළිතුරු කිහිපයක් ඇතැයි සිතුවද, ඒවායින් බොහොමයක් බ්‍රව්සර් සංචාලනය කෙරෙහි අවධානය යොමු කරයි. මම මෙය 2018 දී ලියන අතර බොහෝ විට යමෙකුට ජංගම යෙදුම්වල ආරක්ෂාව ගැන දැන ගැනීමට අවශ්‍ය වනු ඇත.

ජංගම යෙදුම් සඳහා , ඔබ HTTPS භාවිතා කරන තාක් ඔබ යෙදුමේ දෙපැත්ත (සේවාදායකය සහ යෙදුම) පාලනය කරන්නේ නම් ඔබ ආරක්ෂිතයි . iOS හෝ ඇන්ඩ්‍රොයිඩ් විසින් සහතිකය සත්‍යාපනය කර හැකි MiM ප්‍රහාර අවම කරනු ඇත (මේ සියල්ලෙහි ඇති එකම දුර්වල ස්ථානය එයයි). HTTPS සම්බන්ධතා හරහා ඔබට සංවේදී දත්ත යැවිය හැකි අතර එය ප්‍රවාහනයේදී සංකේතනය වනු ඇත . Https හරහා යවන ඕනෑම පරාමිතියක් ඔබගේ යෙදුම සහ සේවාදායකය දැන ගනු ඇත.

මෙහි ඇති එකම “සමහර විට” වනුයේ සේවාදායකයා හෝ සේවාදායකයා අනිෂ්ට මෘදුකාංග වලින් ආසාදනය වී ඇත්නම් එය https ඔතා ගැනීමට පෙර දත්ත දැකිය හැකිය. නමුත් යමෙකු මේ ආකාරයේ මෘදුකාංගයකින් ආසාදනය වී ඇත්නම්, ඔබ එය ප්‍රවාහනය කිරීමට කුමක් භාවිතා කළත් ඔවුන්ට දත්ත වලට ප්‍රවේශය ඇත.

— රිකාඩෝ බී.ආර්.ජී.වෙබ්
source

1

මීට අමතරව, ඔබ ප්‍රතිස්ථාපිත API එකක් ගොඩනඟන්නේ නම්, සේවාදායකයා බ්‍රව්සරයක් නොවිය හැකි අතර ඔබට සබැඳි ක්ලික් කරන පුද්ගලයින් නොසිටින බැවින් බ්‍රව්සර් කාන්දු වීම සහ http යොමු කිරීමේ ගැටළු බොහෝ දුරට අඩු කරනු ලැබේ.

මෙය එසේ නම්, දරන්නා ටෝකනයක් ලබා ගැනීම සඳහා oAuth2 පිවිසුම නිර්දේශ කරමි. කුමන අවස්ථාවකදී එකම සංවේදී දත්ත ආරම්භක අක්තපත්‍ර වනු ඇත ... එය කෙසේ හෝ තැපැල් ඉල්ලීමක තිබිය යුතුය

— ක්‍රිස් රට්ලෙජ්
source

0

ඔබට දැනටමත් ඉතා හොඳ පිළිතුරු ඇති අතර, මෙම වෙබ් අඩවියේ පැහැදිලි කිරීමට මම ඇත්තෙන්ම කැමතියි: https://https.cio.gov/faq/#what-information-does-https-protect

කෙටියෙන්: HTTPS සැඟවීම භාවිතා කිරීම:

HTTP ක්‍රමය
විමසුම් පරාමිතීන්
පෝස්ට් බොඩි (තිබේ නම්)
ශීර්ෂයන් ඉල්ලන්න (කුකීස් ඇතුළත්)
තත්ව කේතය

— pedrorijo91
source

HTTPS URL සංකේතනය කර තිබේද?

කෙටියෙන්:

විධායක සාරාංශය

මාර්තු 2019 යාවත්කාලීන කිරීම

සම්බන්ධතාවය සැකසීමට භාවිතා කරන බැවින් සේවාදායක ලිපින කොටස සංකේතනය කර නොමැත.

මාර්ගය, විමසුම් නූල් ආදිය සංකේතනය කර ඇත.