Universidad Pol Facultad D Trabajo

Total Page:16

File Type:pdf, Size:1020Kb

Universidad Pol Facultad D Trabajo UNIVERSIDAD POLITÉCNICA DE MADRID FACULTAD DE INFORMÁTICA TRABAJO FINAL DE CARRERA ESTUDIO DEL PROTOCOLO XMPP DE MESAJERÍA ISTATÁEA, DE SUS ATECEDETES, Y DE SUS APLICACIOES CIVILES Y MILITARES Autor: José Carlos Díaz García Tutor: Rafael Martínez Olalla Madrid, Septiembre de 2008 2 A mis padres, Francisco y Pilar, que me empujaron siempre a terminar esta licenciatura y que tanto me han enseñado sobre la vida A mis abuelos (q.e.p.d.) A mi hijo icolás, que me ha dejado terminar este trabajo a pesar de robarle su tiempo de juego conmigo Y muy en especial, a Susana, mi fiel y leal compañera, y la luz que ilumina mi camino Agradecimientos En primer lugar, me gustaría agradecer a toda mi familia la comprensión y confianza que me han dado, una vez más, para poder concluir definitivamente esta etapa de mi vida. Sin su apoyo, no lo hubiera hecho. En segundo lugar, quiero agradecer a mis amigos Rafa y Carmen, su interés e insistencia para que llegara este momento. Por sus consejos y por su amistad, les debo mi gratitud. Por otra parte, quiero agradecer a mis compañeros asesores militares de Nextel Engineering sus explicaciones y sabios consejos, que sin duda han sido muy oportunos para escribir el capítulo cuarto de este trabajo. Del mismo modo, agradecer a Pepe Hevia, arquitecto de software de Alhambra Eidos, los buenos ratos compartidos alrrededor de nuestros viejos proyectos sobre XMPP y que encendieron prodigiosamente la mecha de este proyecto. A Jaime y a Bernardo, del Ministerio de Defensa, por haberme hecho descubrir las bondades de XMPP. Y por último, quiero enviarles un grato reconocimiento a todos mis antiguos compañeros de la Facultad de Informática y a los que coincidieron conmigo en su Club de Informática y Telemática, el Capítulo de Estudiantes de ACM, el Grupo de Modelos y Software para el Medio Ambiente (los “Adivinos del Aire” como nos llamó El País en aquel artículo sobre nuestras investigaciones), a los amigos del Laboratorio de Comunicación Oral “Robert Wayne Newcomb” y a muchos más compañeros de la promoción de 1.991 que hicieron de la FIUPM un lugar entrañable y con una ambición de excelencia académica a la que nunca debe renunciar. José Carlos Díaz García Universidad Politécnica de Madrid Facultad de Informática Madrid, 29 de Septiembre de 2.008 I II Índice general 1. Introducción ............................................................................................................ 1 2. Objetivos .................................................................................................................. 5 3. Estado del arte ......................................................................................................... 7 3.1. Fundamentos generales de la MI ....................................................................... 7 3.2. Antecedentes ...................................................................................................... 8 3.2.1. Talkomatic y Term-Talk ............................................................................. 9 3.2.2. Talk de UNIX ............................................................................................ 12 3.2.2.1. Orígenes ............................................................................................. 12 3.2.2.2. Descripción técnica ............................................................................ 13 3.2.3. Internet Relay Chat (IRC) ......................................................................... 14 3.2.3.1. Orígenes ............................................................................................. 14 3.2.3.2. Descripción técnica ............................................................................ 15 3.2.3.3. Clientes .............................................................................................. 18 3.2.3.4. Servidores .......................................................................................... 18 3.2.4. ICQ y el comienzo de la era moderna de la MI......................................... 19 3.2.4.1. Fundamentos del protocolo OSCAR ................................................. 20 3.2.4.2. Formato de los paquetes .................................................................... 21 3.2.4.3. Funcionamiento general del protocolo .............................................. 28 3.2.4.4. Servicios de mensajería y estructura de los mensajes ....................... 29 3.2.5. Jabber y XMPP .......................................................................................... 32 3.2.5.1. Introducción ....................................................................................... 32 3.2.5.2. Orígenes ............................................................................................. 33 3.3. Fundamentos técnicos de XMPP ..................................................................... 35 3.3.1. Arquitectura general del protocolo ............................................................ 35 3.3.2. Direccionamiento ...................................................................................... 37 3.3.3. Estructura de la comunicación basada en XML: Streams y Stanzas ......... 38 3.3.3.1. Negociación de la comunicación: XML Streams .............................. 39 3.3.3.2. TLS: La seguridad en la capa de transporte ....................................... 40 3.3.3.3. Autenticación con SASL ................................................................... 46 3.3.3.4. Comandos: XML Stanzas .................................................................. 52 3.3.4. La mensajería Instantánea en XMPP ........................................................ 53 III 3.3.4.1. Direccionamiento de los mensajes .................................................... 53 3.3.4.2. Estructura de los mensajes ................................................................. 54 3.3.4.3. Listas de Privacidad ........................................................................... 59 3.3.5. La Presencia en XMPP .............................................................................. 60 3.3.5.1. El concepto de presencia ................................................................... 60 3.3.5.2. Descripción técnica del protocolo de presencia ................................ 62 3.3.5.3. Cambios en el estado de presencia de los clientes ............................. 63 3.3.5.4. Suscripciones de presencia ................................................................ 64 3.3.5.5. Manejo del Roster .............................................................................. 67 3.3.5.5.1. Descarga del roster ..................................................................... 69 3.3.5.5.2. Actualización del roster: inserción, modificación y borrado ...... 71 3.3.5.6. Prioridades de los recursos ................................................................ 73 3.3.5.7. Presencia dirigida .............................................................................. 74 3.3.5.8. Presencia final .................................................................................... 75 3.3.5.9. Ejemplos de presencia ....................................................................... 75 3.3.6. Consideraciones de seguridad en XMPP .................................................. 80 3.3.7. Extensiones del protocolo: JEPs/XEPs ..................................................... 81 3.3.7.1. Introducción ....................................................................................... 82 3.3.7.2. Tipos de XEPs ................................................................................... 84 3.3.7.3. Algunas de las XEPs más importantes .............................................. 84 3.3.8. Ejemplo de una sesión XMPP ................................................................... 88 3.3.8.1. Conectar con el servidor de GMail e iniciar sesión ........................... 88 3.3.8.2. El mecanismo de autenticación segura de Gtalk ............................... 97 3.3.8.3. Enviar un mensaje a uno de los contactos ....................................... 100 3.3.8.4. Cambiar el estatus de presencia ....................................................... 101 3.3.8.5. Asociar un Nuevo grupo a un contacto del roster ........................... 102 3.3.8.6. Enviar un fichero a un contacto del roster ....................................... 103 3.3.8.7. Cerrar la sesión ................................................................................ 104 3.3.9. Roadmap.................................................................................................. 104 3.3.10. Software existente ................................................................................. 106 3.3.10.1. Clientes XMPP .............................................................................. 106 3.3.10.2. Servidores XMPP .......................................................................... 110 3.3.10.3. Librerías para el desarrollo de software......................................... 113 IV 3.3.11. Posibilidades del protocolo XMPP ....................................................... 115 3.3.11.1. Transporte entre Jabber/XMPP y otros servidores de MI ............. 116 3.3.11.2. Robots XMPP ................................................................................ 118 3.3.11.3. XMPP como facilitador de los Cloud Services ............................. 119 3.3.11.4. La capacidad P2P ........................................................................... 120 4. Aplicaciones del protocolo XMPP ....................................................................
Recommended publications
  • Download Here
    Seminar Nasional Sistem Informasi Indonesia, 1 Nopember 2016 SECURE REAL TIME PROTOCOL: SOLUSI ALTERNATIF PENGAMANAN CHATTING 1) Donny Seftyanto 1Sekolah Teknik Elektro dan Informatika, Institut Teknologi Bandung Jatinangor, Sumedang, 45363 Telp : (022) 7798600, Fax: (022) 7798617 1) E-mail : [email protected] Abstrak Off The Record (OTR) merupakan protokol kriptografi yang digunakan untuk menjamin keamanan chatting pada banyak aplikasi, seperti Xabber. Tetapi terdapat kelemahan pada protokol ini, yaitu kegagalan otentikasi, penipuan, dan penyangkalan. Untuk memberikan solusi alternatif dalam pengamanan chatting, maka dirancang protokol bernama Secure Real Time (SRT). SRT terdiri dari tiga tahap, yaitu Trusted Public Key Distribution, Key Exchange with Digital Signature, dan Signed and Encrypted Message Transmission with Key Derivation Function. Tahapan tersebut diterapkan dengan algoritma ECDSA-384, ECDH-384, AES-256, dan SHA-384 pada aplikasi Xabber, sehingga memberikan kekuatan keamanan algoritma yang lebih tinggi dari OTR. Lalu berdasarkan hasil evaluasi yang meliputi uji keamanan komunikasi dan pembandingan performa aplikasi Xabber, diketahui bahwa protokol SRT dapat menjamin kerahasiaan, keutuhan, keotentikan, nir-penyangkalan, dan tahan replay attack terhadap data penting di ketiga tahap SRT. Sedangkan tingkat kecepatan dan kemudahan aplikasi Xabber dengan SRT relatif lebih tinggi dari aplikasi Xabber dengan OTR. Kata kunci: chatting, kriptografi, OTR, SRT. Abstract Off The Record (OTR) is cryptographic protocol that is used to ensure the chatting safety in many applications, like Xabber. But there are weaknesses in this protocol, namely authentication failure, fraud, and repudiation. To provide alternative solution in securing chatting, then designed a protocol called Secure Real Time (SRT). SRT consists of three stages, namely The Trusted Public Key Distribution, Key Exchange with Digital Signature, and Signed and Encrypted Message Transmission with Key Derivation Function.
    [Show full text]
  • Relationship of Insects to the Spread of Azalea Flower Spot
    TECHNICAL BULLETIN NO. 798 • JANUARY 1942 Relationship of Insects to the Spread of Azalea Flower Spot By FLOYD F. SMITH Entomologist» Division of Truck Crop and Garden Insect Investigations Bureau of Entomology and Plant Quarantine and FREJEMAN WEISS Senior Pathologist, Division of Mycology and Disease Survey Bureau of Plant Industry UNITED STATES DEPARTMENT OF AGRICULTURE, WASHINGTON* D* C. For sale by the Superintendent of'Documents, Washington, D. G. • Price 10 cents Technical Bulletin No. 798 • January 1942 Relationship of Insects to the Spread of Azalea Flower Spot ^ By FLOYD F. SMITH, entomologist, Division of Truck Crop and Garden Insect Investigations, Bureau of Entomology and Plant Quarantine, and FREEMAN WEISS, senior pathologist. Division of Mycology and Disease Survey, Bureau of Plant Industry ^ CONTENTS Page Page Introduction ' 1 Disease transmission by insects II Insects visiting azaleas and observations on Preliminary studies, 1934 and 1935 11 their habits 2 Improved methods for collecting insects Bumblebees 2 and testing their infectivity 12 Carpenter bees 4 Studies in 1936 18 Ground-nesting bees 5 Transmission of flower spot on heads or Honeybees 5 legs or on pollen from insects- 20 Thrips 5 Transmission tests in 1937 and 1938 20 Ants 5 Relationship of insects to primary infection. 29 Flies 6 Other relationships of insects to the disease 33 Activity of bees in visiting flowers 6 Control experiments with insects on azaleas -. 39 Cause of insect abrasions and their relationship * E fîect of insecticid al dusts on bees 39 to flower spot infection < 7 Eiïect of poisoned sprays on bees 40 Occurrence on insects of conidia of the organ- Discussion of results 40 ism causing azalea flower spot 10 Summary 41 INTRODUCTION A serious spot disease and tlight was first reported in April 1931 near Charleston, S.
    [Show full text]
  • Download Windows Live Messenger for Linux Ubuntu
    Download windows live messenger for linux ubuntu But installing applications in Ubuntu that were originally made for I found emescene to be the best Msn Messenger for Ubuntu Linux so far. It really gives you the feel as if you are using Windows Live Messenger. Its builds are available for Archlinux, Debian, Ubuntu, Fedora, Mandriva and Windows. At first I found it quite difficult to use Pidgin Internet Messenger on Ubuntu Linux. Even though it allows signing into MSN, Yahoo! Messenger and Google Talk. While finding MSN Messenger for Linux / Ubuntu, I found different emesene is also available and could be downloaded and installed for. At first I found it quite difficult to use Pidgin Internet Messenger on Ubuntu Linux. Even though it allows signing into MSN, Yahoo! Messenger. A simple & beautiful app for Facebook Messenger. OS X, Windows & Linux By downloading Messenger for Desktop, you acknowledge that it is not an. An alternative MSN Messenger chat client for Linux. It allows Linux users to chat with friends who use MSN Messenger in Windows or Mac OS. The strength of. Windows Live Messenger is an instant messenger application that For more information on installing applications, see InstallingSoftware. sudo apt-get install chromium-browser. 2. After the installation is Windows Live Messenger running in LinuxMint / Ubuntu. You can close the. Linux / X LAN Messenger for Debian/Ubuntu LAN Messenger for Fedora/openSUSE Download LAN Messenger for Windows. Windows installer A MSN Messenger / Live Messenger client for Linux, aiming at integration with the KDE desktop Ubuntu: Ubuntu has KMess in its default repositories.
    [Show full text]
  • Openfire Service Level Agreement
    Service Level Agreement Technical Services — Communications Service University Technology Services 1. Overview This Service Level Agreement (SLA) is between University Technology Services (UTS) and either departments or groups choosing to utilize the internal Oakland University instant messaging (OUIM) service. The OUIM service is currently referenced by talk.oakland.edu and runs XMPP/Jabber software called Openfire. Under this SLA, UTS agrees to provide specific information technology (IT) services. This SLA also covers performance and reliability targets and objectives. Section 7 requires the signature and contact information of the group coordinator as an agreement to the SLA. OUIM is an online service that is available on campus and off campus. The requirements to utilize the service are a NetID, an XMPP client, and an Internet connection. XMPP clients are available online. The UTS Helpdesk supports the XMPP clients Spark, Pidgin, and Adium. Instructions are available on the UTS Web site at http://www.oakland.edu/?id=13849&sid=70. 2. Purpose The purpose of this SLA is to establish a cooperative partnership between UTS staff members with the community of customers who may opt into its use by clarifying roles, setting expectations, and providing service objectives and limitations. 3. Terms of Agreement This service is provided on an ongoing basis. From time to time, it may be reviewed and modified by UTS. Modifications to this agreement will be done at the sole discretion of UTS and the Technical Support and Services team (TSS). 4. Service Hours Regularly scheduled maintenance will be scheduled during low-use hours as much as possible; such work will be done either before 8:00 A.M.
    [Show full text]
  • XEP-0113: Simple Whiteboarding
    XEP-0113: Simple Whiteboarding Huib-Jan Imbens mailto:jabber@imbens:nl xmpp:imbens@jabber:org 2003-09-07 Version 0.2 Status Type Short Name Deferred Informational Not yet assigned A proposal for an extremely simple whiteboarding protocol over Jabber. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an ”AS IS” BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation,
    [Show full text]
  • Users As Co-Designers of Software-Based Media: the Co-Construction of Internet Relay Chat
    Users as Co-Designers of Software-Based Media: The Co-Construction of Internet Relay Chat Guillaume Latzko-Toth Université Laval AbsTrAcT While it has become commonplace to present users as co-creators or “produsers” of digital media, their participation is generally considered in terms of content production. The case of Internet Relay Chat (IRC) shows that users can be fully involved in the design process, a co-construction in the sense of Science and Technology Studies (STS): a collective, simultaneous, and mutual construction of actors and artifacts. A case study of the early de - velopment of two IRC networks sheds light on that process and shows that “ordinary users” managed to invite themselves as co-designers of the socio-technical device. The article con - cludes by suggesting that IRC openness to user agency is not an intrinsic property of software- based media and has more to do with its architecture and governance structure. Keywords Digital media; Communication technology; Co-construction; Design process; Ordinary user résumé Il est devenu banal de présenter l’usager comme cocréateur ou « produtilisateur » des médias numériques, mais sa participation est généralement envisagée comme une production de contenus. Le cas d’IRC (Internet Relay Chat) montre que les usagers des médias à support logiciel peuvent s’engager pleinement dans le processus de conception, une co-construction au sens des Science and Technology Studies : une construction collective, simultanée et mutuelle des acteurs et des artefacts. Une étude de cas portant sur le développement de deux réseaux IRC éclaire ce processus et montre que les « usagers ordinaires » sont parvenus à s’inviter comme co-concepteurs du dispositif.
    [Show full text]
  • Internet Relay Chat. ERIC Digest
    ED425743 1999-01-00 Internet Relay Chat. ERIC Digest. ERIC Development Team www.eric.ed.gov Table of Contents If you're viewing this document online, you can click any of the topics below to link directly to that section. Internet Relay Chat. ERIC Digest............................................... 1 WHY USE INTERNET RELAY CHAT?..................................... 2 WHAT IS REQUIRED?........................................................ 2 HOW IS IRC ORGANIZED?.................................................. 3 NETS..............................................................................3 CHANNELS......................................................................3 OPS............................................................................... 3 NICKS.............................................................................4 HOW DO YOU FIND, JOIN, OR CREATE A CHANNEL?............... 4 CAN YOU SEND A PRIVATE MESSAGE?................................ 4 HOW DOES ONE EXIT AN IRC CHAT?................................... 4 WHAT ARE THE DISADVANTAGES OF IRC?............................4 WHAT EDUCATIONAL BENEFITS CAN I EXPECT?....................5 ERIC Identifier: ED425743 Publication Date: 1999-01-00 Author: Simpson, Carol Source: ERIC Clearinghouse on Information and Technology Syracuse NY. Internet Relay Chat. ERIC Digest. ED425743 1999-01-00 Internet Relay Chat. ERIC Digest. Page 1 of 6 www.eric.ed.gov ERIC Custom Transformations Team THIS DIGEST WAS CREATED BY ERIC, THE EDUCATIONAL RESOURCES INFORMATION CENTER. FOR MORE
    [Show full text]
  • School and Email Systems
    Email system survey: Top 50 US Colleges US Note Email system Server queried Greeting News School ranking 1 Harvard University Mail2World imap.college.harvard.edu OK Mail2World IMAP4 Server 2.5 ready Sun Java SMS imap.princeton.edu OK [CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS CHILDREN BINARY LANGUAGE XSENDER X-NETSCAPE XSERVERINFO Princeton University 1 AUTH=PLAIN] Messaging Multiplexor (Sun Java(tm) System Messaging Server 6.2-5.05 (built Feb 16 2006)) Unknown mail.yale.edu OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN] pantheon-po14.its.yale.edu IMAP4rev1 2002.336 at Mon, 26 Jul 2010 14:10:23 Yale University 3 -0400 (EDT) Dovecot imap-server.its.caltech.edu OK Dovecot ready. Cyrus mail.alumni.caltech.edu OK posteaux1.caltech.edu Cyrus IMAP4 v2.2.12-Invoca-RPM-2.2.12-10.el4_8.4 server ready 4 California Institute of Technology Dovecot imap.gps.caltech.edu OK dovecot ready. Dovecot theory.caltech.edu OK dovecot ready. 4 Massachusetts Institute of Technology Unable to find a server to query (username.mail.mit.edu)Unknown 4 Stanford University Zimbra zm01.stanford.edu OK zm01.stanford.edu Zimbra IMAP4rev1 server ready Zimbra mailbox.zimbra.upenn.edu OK mailbox.zimbra.upenn.edu Zimbra IMAP4rev1 service ready 4 University of Pennsylvania Exchange 2010 webmail.wharton.upenn.edu OK The Microsoft Exchange IMAP4 service is ready. Dovecot imap.nevis.columbia.edu OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready. Lotus Domino equinox.law.columbia.edu OK Domino IMAP4
    [Show full text]
  • Initial Study / Environmental Assessment Annotated
    This page has been intentionally left blank. This page has been intentionally left blank. SCH: PROPOSED MITIGATED NEGATIVE DECLARATION Pursuant to: Division 13, Public Resources Code Project Description The Los Angeles County Metropolitan Transportation Authority (Metro), in cooperation with the Gateway Cities Council of Governments and the California Department of Transportation (Caltrans) District 7, proposes to develop and implement an auxiliary lane on Eastbound State Route 91 within a 1.4-mile segment from the southbound Interstate 710 (I-710) interchange connector to eastbound State Route 91, to Cherry Avenue. The Study Area includes Eastbound State Route 91 (Post Miles [PM] R11.8/R13.2) and is located in the City of Long Beach and adjacent to the City of Paramount, California. Determination This proposed Mitigated Negative Declaration is included to give notice to interested agencies and the public that it is Caltrans’ intent to adopt a Mitigated Negative Declaration for this project. This does not mean that Caltrans’ decision regarding the Project is final. This Mitigated Negative Declaration is subject to change based on comments received by interested agencies and the public. All Project features (including standard practices and specifications) are considered in significance determinations. Caltrans has prepared an Initial Study for this project and, pending public review, expects to determine from this study that the proposed Project would not have a significant effect on the environment for the following reasons: The Project would have no effect on aesthetics, agriculture and forest resources, cultural resources, energy, land use and planning, mineral resources, population and housing, recreation, tribal cultural resources, and wildfire.
    [Show full text]
  • Novell Messenger 3.0 May 2015
    Novell Messenger 3.0 May 2015 1Overview The information in this Readme file pertains to Novell Messenger 3.0. Novell Messenger 3.0 offers enhanced functionality over prior Messenger versions: Mobile Applications: Novell Messenger 3.0 provides native applications for iOS, Android, and BlackBerry devices. For more information, see “Using Novell Messenger on Your Mobile Device” in the Novell Messenger 3.0 Client User Guide. For information about the administrative tasks associated with Messenger mobile applications, see “Managing Messenger Mobile Applications” in the Novell Messenger 3.0 Administration Guide. Simultaneous Client Connections: Novell Messenger 3.0 allows you to maintain simultaneous connections to your Messenger system from multiple workstations or devices. For example, you can be connected to Messenger on your workstation, and then connect to Messenger from a mobile device without being logged out of Messenger on your workstation. For more information about this feature, see “Limiting Physical Access to Client Workstations” in “Securing Novell Messenger” in the Novell Messenger 3.0 Administration Guide. Update Clients (Look and Feel): Novell Messenger 3.0 provides an updated look and feel for both the Windows and Linux/Mac client interfaces. The Messenger 3.0 release also contains the following changes: Removal of NetWare support: With Messenger 3.0 and later, NetWare is no longer supported. ConsoleOne download option: If you have not already installed ConsoleOne, it is available with the Messenger distribution. 2 System Requirements Novell Messenger 3.0 system requirements (including requirements for mobile devices) are listed in “Novell Messenger Hardware and Software Requirements” in the Novell Messenger 3.0 Installation Guide.
    [Show full text]
  • Communigate Pro Voip Administrator Training
    CommuniGate Pro Real-Time Features CommuniGate Pro ● Internet Communications ● VoIP, Email, Collaboration, IM ● www.communigate.com CommuniGate Pro for VoIP Administrators • Audience: Server Administrators and Developers • Focus: CommuniGate Pro as the Signaling platform • Method: Understanding CommuniGate Pro operation for Real-Time Signaling services. “How it works” • Goal: Learn what CommuniGate Pro can do for you. CommuniGate Pro ● Internet Communications ● VoIP, Email, Collaboration, IM ● www.communigate.com Who is CommuniGate Systems • Founded • Communications Software • Focus on electronic mail and collaboration • Standards • Carrier Grade • Real-Time Communications • CommuniGate Pro CommuniGate Pro ● Internet Communications ● VoIP, Email, Collaboration, IM ● www.communigate.com What is CommuniGate Pro • Self-contained single package • Multithreaded • Multiplatform • Flexible • Extensible • Not just a product – it’s a platform CommuniGate Pro ● Internet Communications ● VoIP, Email, Collaboration, IM ● www.communigate.com Data Storage • Hierarchical – Logically – Physically • Efficient • Settings, Mail, Metadata, Templates, Middleware, Software CommuniGate Pro ● Internet Communications ● VoIP, Email, Collaboration, IM ● www.communigate.com System Kernel • Multithreading • Disk I/O • Network I/O • OS interfaces • Everything Else CommuniGate Pro ● Internet Communications ● VoIP, Email, Collaboration, IM ● www.communigate.com Standard Protocols • SMTP • POPPWD • POP3 • RADIUS • IMAP • TFTP • ACAP • SNMP • LDAP • SYSLOG • HTTP • FTP
    [Show full text]
  • A User Study of Off-The-Record Messaging
    A User Study of Off-the-Record Messaging Ryan Stedman Kayo Yoshida Ian Goldberg University of Waterloo 200 University Avenue West Waterloo, Ontario, Canada N2L 3G1 {rstedman@cs, k2yoshid@math, iang@cs}.uwaterloo.ca ABSTRACT Keywords Instant messaging is a prevalent form of communication ac- OTR, Usable Security, Instant Messaging, Think Aloud ross the Internet, yet most instant messaging services pro- vide little security against eavesdroppers or impersonators. 1. INTRODUCTION There are a variety of existing systems that aim to solve There has been much research into creating privacy-en- this problem, but the one that provides the highest level hancing technologies, especially since the Internet has started of privacy is Off-the-Record Messaging (OTR), which aims to play an essential role in everyday life. However, not many to give instant messaging conversations the level of privacy of these technologies have seen widespread adoption. One available in a face-to-face conversation. In the most recent of the reasons for this is that many of these technologies redesign of OTR, as well as increasing the security of the provide insufficient usability [8]. protocol, one of the goals of the designers was to make OTR The process of evaluating and enhancing usability is im- easier to use, without users needing to understand details of portant in order for a privacy-enhancing technology to pro- computer security such as keys or fingerprints. vide benefits to ordinary users. Since privacy is not just To determine if this design goal has been met, we con- intended for computer scientists or cryptographers, but for ducted a user study of the OTR plugin for the Pidgin in- everyone, these technologies should be accessible to the gen- stant messaging client using the think aloud method.
    [Show full text]