https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=WebFund_2024F_Lecture_16 2026-04-22T14:38:25Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=WebFund_2024F_Lecture_16&diff=24843&oldid=prev 2024-11-12T22:59:33Z

<p>Created page with &quot;==Video== Video from the lecture for November 12, 2024 is now available: * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec16-20241112.m4v video] * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec16-20241112.cc.vtt auto-generated captions] ==Notes== &lt;pre&gt; Lecture 16 ---------- - midterm is being graded, should hopefully be done by end of the week - Assignment 2 should finally be uploaded later...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture for November 12, 2024 is now available:<br /> * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec16-20241112.m4v video]<br /> * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec16-20241112.cc.vtt auto-generated captions]<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 16<br /> ----------<br /> <br /> - midterm is being graded, should hopefully be done by end of the week<br /> - Assignment 2 should finally be uploaded later today (sorry!)<br /> <br /> - Q7 on A3: your analysis page should have 5 or 6 extra numbers, one per question (it is 5 or 6 depending on whether you are modifying your code with the extra question or not)<br /> Q3 has 5 blank submissions<br /> Q5 has 20 blank submissions<br /> <br /> Since you also report on the total number of submissions, with these stats you can see what fraction of students left a question blank<br /> <br /> --------------<br /> <br /> Today: cookies &amp; TLS<br /> <br /> We previously discussed how http is a stateless protocol<br /> <br /> But sometimes we need state<br /> - most commonly, when we &quot;log in&quot; to a website<br /> - but is also used for site preferences (theme), other tasks<br /> - and of course, tracking for advertising targeting<br /> <br /> Most common mechanism for adding state to http is the &quot;cookie&quot; mechanism<br /> <br /> But what is a cookie?<br /> - data set by the server with a &quot;Set-Cookie:&quot; header<br /> - later requests to the server get the added header &quot;Cookie: &quot; with the value<br /> of the cookies that were previously set<br /> - allows the server to &quot;save&quot; data on the client (browser) that will be given back to it<br /> - remember, servers talk to many clients, so things like cookies<br /> help the server distinguish them from each other<br /> <br /> - But remember, cookies are just data included in an HTTP header<br /> - so anyone can set any cookie<br /> - only way to be secure is to 1) make sure it isn&#039;t sent to the wrong<br /> sites and 2) make sure it isn&#039;t guessable<br /> <br /> <br /> <br /> Web Server Browser<br /> &lt;--- GET /index.html<br /> <br /> contents of index.html ----&gt; renders index.html, saves user=bob<br /> + Content-Type: text/html cookie for this server<br /> + Set-Cookie: user=bob<br /> <br /> <br /> &lt;--- GET /index.html<br /> + Cookies: user=bob<br /> <br /> contents of index.html ---&gt; <br /> for the user bob<br /> <br /> <br /> Any browser can set any cookie<br /> - if you can guess a cookie that allows you to get confidential information,<br /> that cookie is insecure (as is the web app)<br /> - if you can steal the cookie, you have some sort of hijacking attack<br /> - and can potentially be stolen by just impersonating the right site<br /> <br /> <br /> So why is it called cookie?<br /> - this is actually an old term<br /> - used by the X Window system, which predates the web<br /> - used as a general term for data stored that is opaque to the storer &amp;<br /> used for authentication &amp; session management<br /> <br /> Note that a browser has NO OBLIGATION to store a cookie for a website<br /> - it can forget it immediately<br /> - it can forget it later<br /> <br /> Browsers generally shouldn&#039;t modify cookies, but they can easily forget them<br /> <br /> <br /> Why is it a cookie?<br /> - I think someone was hungry<br /> <br /> What does it mean for a cookie to be secure?<br /> - that is separate from secure cookie handling, which needs other technology<br /> - essentially, the cookie should not be guessable by unauthorized parties<br /> - so if you have a cookie that represents that a user is logged in,<br /> unauthorized users shouldn&#039;t be able to guess it, otherwise<br /> they can be logged in as well, even if they don&#039;t know the password<br /> <br /> This is why you have to keep logging in on the web<br /> - everyone is paranoid about cookies being stolen, so they<br /> make them valid only for a limited period of time<br /> <br /> But remember, http is sent in the clear over the Internet<br /> - anyone could be snooping<br /> - and if they are listening in, they can grab any important cookies<br /> and use them for bad purposes<br /> - doesn&#039;t matter if they are secure cookies or not!<br /> <br /> This is why almost all web traffic today is encrypted, using the protocol https<br /> - https is HTTP over TLS<br /> - TLS = transport layer security<br /> - used to be SSL = secure sockets layer<br /> - decided to have a more general name for a more general mechanism<br /> <br /> TLS can be used to secure any TCP/IP data stream<br /> - email (POP3, IMAP, SMTP) uses TLS today<br /> - basically any regular protocol can be put over TLS to make it &quot;secure&quot;<br /> <br /> But the security guarantees of TLS are very specific and have very strict requirements<br /> <br /> So if the assumptions of TLS hold, then you get<br /> - no eavesdropping (confidentiality)<br /> - even if traffic was recorded, can&#039;t be decoded later even if both parties are compromised later (perfect forward secrecy)<br /> - no undedectable tampering (modifications just end communication with an error) (integrity)<br /> - one-sided or two-sided authentication<br /> - you either know who the server is, or you know who both the server &amp; client are<br /> - on the web today we almost always do one-sided authentication<br /> (username/password/2FA are used for the other direction, not TLS)<br /> <br /> In TLS, entities are identified with certificates. A certificate has<br /> - the public key of the entity<br /> - associated metadata (name of organization/server, how long valid, etc.)<br /> <br /> In public key cryptography, you have public keys and private keys<br /> - public keys are given away<br /> - private keys must be private!<br /> <br /> A private key is used to decrypt or sign data<br /> A public key is used to encrypt or verify signatures<br /> <br /> If you publish your public key<br /> - anyone can send you a secret message, but only you can read it<br /> - only you can sign a document as you, but anyone can verify that signature<br /> <br /> Digital signatures are cool because they say who signed it and that the document has not been modified at all<br /> - much better than signatures on paper!<br /> &lt;/pre&gt;</div>

Soma