[SSL] verschil S-SMTP en bijv. https protocol

[bille]

Ik heb het één en ander bij elkaar gezocht mbt verschillen in protocollen. Wat mij op valt is het volgende:
- Wanneer ik wil communiceren met een SMTP server die SSL beveiligd is dan volstaat het niet langer een SSL tunneltje te maken en daar standaard SMTP over te spreken. Hier onder een voorbeeld van hoe de communicatie verloopt bij secure SMTP:

S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.ietf.org
S: 250-mail.imc.org offers a warm hug of welcome
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: <continues by sending an SMTP command>

(http://www.faqs.org/rfcs/rfc2487.html)
Wat opzich opvalt is dus dat er tijdens de standaard smtp communicatie een verbinding wordt gemaakt gebruik makend van het TLS protocol. Feitelijk verandert hiermee het SMTP protocol.

Wanneer men kijkt naar het HTTPS protocol is dit feitelijk niets anders dan HTTP communicatie via een SSL (of de modernere variant TLS) tunnel. Echter veranderd er niets aan het HTTP cmd. Het is niet dat je tijdens het doen van een POST/GET de TLS verbinding moet gaan aanmaken. Het volstaat in dat geval éérst een SSL tunneltje aan te leggen om vervolgens over die tunnel HTTP te praten.

In onze applicatie (een Omnis toepassng) hebben we enkele componenten die bijv. HTTP, POP3 en SMTP comm. afhandelen. Nu blijkt dus dat er voor SMTP een nieuw component geschreven moet worden, daar dat niet nodig is voor https of pop3. Bij die laatste volstaat het namelijk eerst ff met bijv. Stunnel (http://www.stunnel.org/ ) een SSL connectie te maken om vervolgens gewoon gebruik te maken van het HTTP/POP3 component.

Heeft iemand enig id wat de motivatie is geweest om het SMTP protocl wél te verbouwen, maar andere protocollen niet?

[Maurits van Baerle]

Zou het niet te maken kunnen hebben met voortschrijdend inzicht? Je moet bij het (oudere https) als client nu eerst bepalen (explicit) dat je secure wil (door direct poort 443 te benaderen) en dan moeten beiden nog gaan onderhandelen om te kijken of er uberhaupt overeenstemming bereikt kan worden over de te gebruiken encryptie. Minder flexibel en er moet een extra poort open.

Met SMTP kan al het verkeer over dezelfde poort (25) verlopen. Er is wel een gereserveerde poort voor (465) maar dankzij TLS hoef je die niet meer te gebruiken (implicit). Er wordt gewoon over poort 25 contact gelegd en dan door beide partijen overeenstemming bereikt over het wel of niet gebruiken van encryptie, beide partijen hebben daarbij de mogelijkheid om encryptie te verplichten. Het voordeel is dat je nu niet vantevoren als client naar een poort hoeft die alleen encrypted kan communiceren en er hoeft maar één poort open.

Die laatste optie klinkt mij logischer (moderner) in de oren en is denk ik de reden geweest om daar voor te kiezen. Volgens mij gebruikt bijvoorbeeld Secure FTP (FTPS) dezelfde methode als SMTP over TLS (gewoon implicit op poort 21), ook zo'n protocol dat later kwam dan HTTPS.