SSTP మరియు SSL 3.0: లేబుల్ వర్సెస్ బేరమాడిన వెర్షన్

ఇద్దరు వ్యక్తులు ఒకే SSTP అమరికను చూసి వ్యతిరేక ముగింపులకు చేరుకోవచ్చు. ఒకరు ఉత్పత్తి పత్రాన్ని చదివి, SSL అక్షరాలు చూసి, సంవత్సరాల క్రితం తొలగించిన ప్రోటోకాల్‌ను ఆ సొరంగం నడుపుతోందని భావిస్తారు. మరొకరు ఆధునిక హ్యాండ్‌షేక్‌ను చూపి, ప్రశ్న ముగిసిందని అంటారు. ఇద్దరూ లేబుళ్ల ఆధారంగా వాదిస్తారు, బేరమాడిన వెర్షన్ ఆధారంగా కాదు, ఇందులో ఒకటి మాత్రమే సాక్ష్యం. చేయదగిన పోలిక పేరు ఏం వాగ్దానం చేస్తుంది, సేవ నిజంగా ఏమి ఎంచుకుంటుంది అనే దాని మధ్య ఉంది.

ఒకే ప్రశ్నకు రెండు సమాధానాలు

లేబుల్ వాదాన్ని చెప్పడం సులభం: SSTP ను సురక్షిత సాకెట్ టన్నెలింగ్ ప్రోటోకాల్ అని వర్ణిస్తారు, చారిత్రక పేరు SSL అంటుంది, కాబట్టి కనెక్షన్ SSL 3.0 గా ఉండాలి. అది నిలబడటానికి కారణం పేరు నిజంగా ఆ వంశం నుండి వచ్చింది, మరియు దాన్ని పునరావృతం చేసేవారిలో చాలామంది ఎప్పుడూ హ్యాండ్‌షేక్ చూడలేదు. ముగింపు జాగ్రత్తగా వినిపిస్తుందని కూడా అది నిలబడుతుంది, అత్యంత చెడ్డది ఊహించుకోవడమే సురక్షిత ఎంపిక అన్నట్టు. అత్యంత చెడ్డది ఊహించడం, నిజమైన వెర్షన్‌ను కొలవడం వేర్వేరు పనులు, వీటిలో ఒకటి మాత్రమే ఏదో మారుస్తుంది.

సాక్ష్యం వాదం మరింత సన్నిహిత ప్రశ్న అడుగుతుంది. ఈ క్లయింట్ మరియు ఈ సర్వర్ ఈ ఎండ్‌పాయింట్‌లో, ఈ సమయంలో ఏ ప్రోటోకాల్ వెర్షన్‌పై అంగీకరించాయి? సమాధానం TLS ను ముగించే సేవ నుండి వస్తుంది, ఏదైనా మార్కెటింగ్ పేజీ నుండి లేదా పోలిన పేరు గల సైట్‌ను చేరిన బ్రౌజర్ నుండి కాదు.

రెండు వాదాలు ఏమి నిరూపించగలవు అనే దానిలో భిన్నంగా ఉంటాయి. లేబుల్ పాత అమరికను ప్యాచ్ చేసిన దాని నుండి వేరు చేయలేదు, హ్యాండ్‌షేక్ అదే హోస్ట్‌పై ఉన్న సంబంధం లేని సేవ ఏమి చేస్తోందో చెప్పలేదు. రెండవదాన్ని ఉపయోగించండి, మొదటిదాన్ని ఉపయోగించడం ఆపండి.

సేవ నిజంగా ఎంచుకునే వెర్షన్‌ను చదవండి

భాగాలను పేర్కొనడంతో ప్రారంభించండి: క్లయింట్ అమలు, సర్వర్ అమలు, TLS ఎండ్‌పాయింట్, మరియు వాటి మధ్య TLS ను ముగించి తిరిగి ఏర్పాటు చేసే ప్రతిదీ. TLS ను ముగించి బ్యాకెండ్‌తో సాదా HTTP మాట్లాడే లోడ్ బ్యాలెన్సర్, మీరు ఏ పరికరం విధానాన్ని చదవాలో మారుస్తుంది.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

ఫలితంతో పాటు ఎండ్‌పాయింట్ మరియు సమయాన్ని నమోదు చేయండి, ఎందుకంటే తర్వాత విధానం మారితే తేదీ లేని పరిశీలన నిష్ప్రయోజనం. మీకు ముఖ్యమైన వినియోగదారులు ఉన్న అదే నెట్‌వర్క్ మార్గంలోని క్లయింట్ నుండి పరీక్షను పునరావృతం చేయండి, ఎందుకంటే అడ్డుపడే పరికరం తన సెట్టింగ్‌లతో TLS ను ముగించగలదు. రెండు స్థానాలు సరిపోలకపోతే, ముఖ్యమైన భాగాన్ని కనుగొన్నారు. సరిపోలితే, నినాదం బదులు మీకు సాక్ష్యం ఉంది.

రికార్డ్ ఫీల్డ్‌ను బేరం నుండి వేరు చేయండి

ఒక ఫీల్డ్‌లో పాతదిగా కనిపించే వెర్షన్ సంఖ్య SSL 3.0 సెషన్‌తో సమానమైన వాస్తవం కాదు. RFC 7568 రికార్డ్ పొర వెర్షన్‌ను మరియు బేరమాడిన ప్రోటోకాల్‌ను వేర్వేరు విషయాలుగా పరిగణిస్తుంది, ఈ భేదం నుండే విశ్వాసపూర్వక తప్పు సమాధానాలు వస్తాయి. బేరమాడిన ప్రోటోకాల్ చదవండి, తర్వాత సైఫర్, ఆ తర్వాతే సెషన్ గురించి ముగింపుకు రండి.

అదే పత్రం ప్రోటోకాల్ గురించి స్పష్టంగా ఉంది: SSL 3.0 ఉపయోగించకూడదు, దానిపై బేరం లేదా వెనక్కి వెళ్లడం నిషేధించబడింది. కారణం POODLE దాడి ఉపయోగించుకున్న విరిగిన CBC నిర్మాణం, అది ప్రోటోకాల్ లక్షణం, ఒక అనువర్తన అమరిక కాదు.

అందుకే “ఈ భారాన్ని దోపిడీ చేయడం కష్టం” అనేది SSL 3.0 ను ప్రారంభంలో ఉంచడానికి వాదం కాదు. అవసరం ప్రోటోకాల్‌ను తొలగించడం, ఒక ప్రదర్శనపై చర్చను గెలవడం కాదు.

SSL 3.0 ను మీరు సమర్థించగల విధానంతో వెనక్కి తీసుకోండి

Windows లో Schannel ప్రోటోకాల్ సెట్టింగ్‌లు Protocols కీ కింద ఉంటాయి, క్లయింట్ మరియు సర్వర్ పాత్రలకు విడివిడిగా చదవబడతాయి, అందుకే ఒక దిశను సరిచేసే మార్పు మరొక దిశను తాకకుండా వదిలేయగలదు. ప్రస్తుత సెట్టింగ్‌లు మరియు వాటి రీస్టార్ట్ అవసరాలను Microsoft పత్రీకరించింది, అదే హోస్ట్‌పై ఉన్న తృతీయ పక్ష TLS లైబ్రరీ వాటిని పూర్తిగా విస్మరిస్తుంది.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

విధానాన్ని మద్దతు ఉన్న నిర్వహణ మార్గం ద్వారా మార్చండి, యజమాని సేవ తన అమరికను తిరిగి పొందుతుందని నిర్ధారించండి, తిరిగి వెళ్లడానికి ఆమోదిత మార్గాన్ని ఉంచండి. మరొక వాతావరణం నుండి విస్తృత రిజిస్ట్రీ స్క్రిప్ట్‌ను అతికించడమే ఒక సేవ సవరణ యంత్రంలోని ప్రతి TLS క్లయింట్‌కు అడ్డంకిగా మారే మార్గం. ఇక్కడ రీస్టార్ట్ పరిధి ముఖ్యం: వర్తించినట్టు కనిపించే సెట్టింగ్ దాన్ని తిరిగి లోడ్ చేయని సేవ మెమరీలో ఇంకా ఉండవచ్చు.

ఇంకా వాడుకలో లేని వెర్షన్‌ను కోరుతున్న భాగస్వామికి నవీకరణ లేదా వలస ప్రణాళిక అవసరం. పాత ప్రోటోకాల్‌ను నిశ్శబ్దంగా పునరుద్ధరించే పత్రీకరించని మినహాయింపు అనుకూలత వ్యూహం కాదు, తదుపరి ఆడిట్ వరకు నిలబడదు.

మార్పును కొత్త కనెక్షన్లతో అంగీకరించండి

విధాన మార్పు తర్వాత కొత్త సెషన్లతో పరీక్షించండి, ఎందుకంటే మార్పుకు ముందు ఏర్పడిన కనెక్షన్ ఇప్పుడు అమలులో ఉన్న అమరిక గురించి ఏమీ నిరూపించదు. ఆమోదిత ప్రోటోకాల్ విజయవంతమవుతుందని, నిషేధిత ప్రోటోకాల్ అధికృత ధ్రువీకరణ ప్రక్రియలో విఫలమవుతుందని నిర్ధారించండి, తర్వాత సర్టిఫికెట్ గుర్తింపు మరియు విశ్వాస తనిఖీలను ఉన్నట్టుగానే ఉంచండి.

హ్యాండ్‌షేక్ ఏమి కవర్ చేయదో గుర్తుంచుకోండి. SSTP TLS పొర తర్వాత PPP ప్రామాణీకరణను తీసుకువెళ్తుంది, కాబట్టి ఆధునిక ప్రోటోకాల్ వెర్షన్ ఏ వినియోగదారు అధికృతుడయ్యాడు లేదా సెషన్ ఏ వనరులను చేరగలదు అనే దాని గురించి ఏమీ చెప్పదు. ఇవి వేర్వేరు నియంత్రణలు వేర్వేరు సాక్ష్యాలతో.

ఫలితాన్ని సేవ, బ్యాకెండ్, ఆమోదిత విధానం మరియు గమనించిన వెర్షన్‌గా రాయండి. అలాంటి నమోదు భద్రతా ప్రశ్నకు కచ్చితంగా సమాధానం ఇస్తుంది, లేబుల్ వాదం గానీ అసౌకర్య వాదం గానీ దాన్ని ఎప్పుడూ చేయవు.