🔒 धडा 08 — TLS आणि certificates: सील केलेला लखोटा

📍 तुम्ही इथे आहात: 12 पैकी धडा 08 · पुढे: lesson-09-routing

📦 या ब्रँचमध्ये काय आहे

धडे 01–08. Certificates, त्यांच्यावर सही करणारी authority, handshake, आणि Python मध्ये खरे certificate वाचणे.

net/demo.py — tls: example.com:443 सोबत handshake; protocol, cipher, subject, issuer, expiry, पर्यायी नावे

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

साधा लखोटा corridor मधला कोणीही उघडू शकतो. सील केलेला लखोटा उघडता येत नाही — पण सील कोणाचे आहे हे माहीत असेल तरच त्याचा उपयोग. म्हणून server एक ओळखपत्र (certificate) दाखवतो: "मी example.com आहे", ज्यावर सगळ्यांचा विश्वास असलेल्या मुख्य कार्यालयाची (certificate authority) सही असते. तुमचा browser सही आणि नाव तपासतो, मग तुम्ही दोघे यापुढचा प्रत्येक लखोटा सील करण्याची एक गुप्त पद्धत ठरवता. हेच TLS आहे; HTTPS म्हणजे त्याच्या आतले HTTP.

🗺️ आकृती

sequenceDiagram
  participant B as browser
  participant S as example.com :443
  B->>S: ClientHello (SNI: example.com, ciphers I speak)
  S->>B: ServerHello + certificate (signed by a CA) + key share
  B->>B: verify chain · check name · check dates
  B->>S: Finished — session keys agreed
  Note over B,S: everything after is encrypted and tamper-proof

❓ काय

certificate एका public key ला नावांशी (CN, subjectAltName) बांधते, वैधतेच्या तारखांसह, आणि त्यावर CA ची सही असते. Browsers सोबत विश्वासू CAs ची यादी येते.
chain: leaf → intermediate → root. server leaf आणि intermediates पाठवतो; root तुमच्या machine वर आधीच असतो.
SNI: client पहिल्याच संदेशात त्याला कोणते नाव हवे ते सांगतो, त्यामुळे एका पत्त्यावर अनेक certificates ठेवता येतात.
TLS 1.3: एक round trip, फक्त मजबूत ciphers, forward secrecy. जुने versions बंद करण्यासाठीच अस्तित्वात आहेत.
TLS काय सिद्ध करते: तुम्ही त्या नावाची key असलेल्याशी बोलत आहात, आणि मधला कोणीही वाचू किंवा बदलू शकत नाही. काय सिद्ध करत नाही: site प्रामाणिक आहे, किंवा content सुरक्षित आहे.

🤔 का

कोणीही न आखलेल्या outages च्या पहिल्या तीन कारणांपैकी एक म्हणजे expire झालेले certificates. चुकीची नावे, गहाळ intermediates आणि production मधले self-signed certificates ही बाकीची. एकदा केले की certificate वाचायला दहा seconds लागतात.

🔧 कसे (या repo मध्ये)

tls() एक TCP socket ssl.create_default_context() ने गुंडाळतो (जो विश्वासू CAs load करतो आणि नाव तपासतो), मग version(), cipher(), आणि getpeercert() मधली fields छापतो.

🧪 करून पाहा

python3 net/demo.py tls
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | grep -E 'subject=|issuer=|Verify'
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
curl -sv https://expired.badssl.com 2>&1 | grep -iE 'expired|SSL certificate' | head -2     # what a broken seal looks like

✅ तपासा — तुम्हाला काय दिसायला हवे

protocol TLSv1.3 (किंवा 1.2), issuer संस्था, भविष्यातली valid until तारीख, आणि also valid for: ['example.com', '*.example.com']. badssl ची तपासणी expiry error देऊन fail होते — मुद्दाम.

🏁 तुम्ही आत्ताच काय सिद्ध केले

एखाद्या site ची हमी कोण देतो आणि कधीपर्यंत हे तुम्ही वाचू शकता — आणि सील तुटण्याचे तीन प्रकार ओळखू शकता.

⚠️ नेहमीच्या चुका

"चालावे म्हणून" verification बंद करणे (verify=False, -k). तुम्ही ते असुरक्षित केले.
intermediate certificate विसरणे: एका browser मध्ये चालते, दुसऱ्यात fail होते.
automation शिवाय 90 दिवसांचे Let's Encrypt certificate. 91 वा दिवस म्हणजे outage.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: certificate expiry monitoring, load balancers वरचे SNI, services मधले mTLS (API शाळा धडा 14) आणि स्वागत कक्षावर होणारे TLS termination (धडा 11) — हे सगळे मोठ्या प्रमाणावरचा हाच handshake आहेत.

⏭️ पुढे

धडा 09 — routing आणि internet: कोणाकडेच पूर्ण नकाशा नसलेली इमारत पिशवी कशी शोधते.

🔒 Lesson 08 — TLS & certificates: the sealed envelope

📍 You are here: Lesson 08 of 12 · Next: lesson-09-routing

📦 What's in this branch

Lessons 01–08. Certificates, the authority that signs them, the handshake, and the reading of a real certificate in Python.

net/demo.py — tls: a handshake with example.com:443; protocol, cipher, subject, issuer, expiry, alternative names

🧒 Explain like I'm 5

A plain envelope can be opened by anyone on the corridor. A sealed envelope cannot — but a seal only helps if you know whose seal it is. So the server shows an ID card (the certificate): "I am example.com", signed by a head office everyone trusts (a certificate authority). Your browser checks the signature and the name, then the two of you agree a secret way to seal every envelope from now on. That is TLS; HTTPS is HTTP inside it.

🗺️ Diagram

sequenceDiagram
  participant B as browser
  participant S as example.com :443
  B->>S: ClientHello (SNI: example.com, ciphers I speak)
  S->>B: ServerHello + certificate (signed by a CA) + key share
  B->>B: verify chain · check name · check dates
  B->>S: Finished — session keys agreed
  Note over B,S: everything after is encrypted and tamper-proof

❓ What

A certificate binds a public key to names (CN, subjectAltName), with validity dates, signed by a CA. Browsers ship a list of trusted CAs.
The chain: leaf → intermediate → root. The server sends the leaf and intermediates; the root is already on your machine.
SNI: the client says which name it wants in the first message, so one address can host many certificates.
TLS 1.3: one round trip, only strong ciphers, forward secrecy. Older versions exist to be turned off.
What TLS proves: you are talking to the holder of that name's key, and nobody in between can read or alter. What it does not prove: that the site is honest, or that the content is safe.

🤔 Why

Expired certificates are a top-three cause of outages nobody planned. Wrong names, missing intermediates and self-signed certificates in production are the others. Reading a certificate takes ten seconds once you have done it.

🔧 How (in this repo)

tls() wraps a TCP socket with ssl.create_default_context() (which loads the trusted CAs and verifies the name), then prints version(), cipher(), and fields from getpeercert().

🧪 Try it

python3 net/demo.py tls
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | grep -E 'subject=|issuer=|Verify'
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
curl -sv https://expired.badssl.com 2>&1 | grep -iE 'expired|SSL certificate' | head -2     # what a broken seal looks like

✅ Verify — what you should see

protocol TLSv1.3 (or 1.2), an issuer organisation, a valid until date in the future, and also valid for: ['example.com', '*.example.com']. The badssl check fails with an expiry error — on purpose.

🏁 What you just proved

You can read who vouches for a site and until when — and recognise the three ways a seal breaks.

⚠️ Common mistakes

Turning off verification (verify=False, -k) to "make it work". You made it insecure.
Forgetting the intermediate certificate: works in one browser, fails in another.
A 90-day Let's Encrypt certificate with no automation. Day 91 is an outage.

🏭 Why this matters in production: certificate expiry monitoring, SNI on load balancers, mTLS between services (API school lesson 14) and TLS termination at the reception desk (lesson 11) are this handshake at scale.

⏭️ Next

Lesson 09 — routing & the internet: how a bag finds a building nobody has a full map to.

← Previoushttp on the wire Next →routing

This page is the lesson's README from the lesson-08-tls branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.