Grain Management Adds Private Equity Pioneer Cleveland A. Christophe As Senior Advisor
28 Sep Grain Management Adds Private Equity Pioneer Cleveland A. Christophe As Senior Advisor
WASHINGTON–(BUSINESS WIRE)–Grain Management, LLC (“Grain”), a leading investment firm that focuses on innovative companies, technologies, and assets in the communications sector, announced today that trailblazing investor, Cleveland Christophe, has joined its board as a Senior Advisor.
Christophe spent two decades as an executive with Citibank, including its venture capital unit, equity investment research department, and several years in San Francisco where he served as head of corporate banking for the high technology industries, including Silicon Valley. Christophe is best known for engineering the largest leveraged buyout of offshore assets in history, the purchase of Beatrice International Food Company by TLC Group in 1987. Five years later, Christophe co-founded private equity investment firm TSG Capital Group, where he served as Managing Partner from 1994 to 2008. Prior to his retirement in 2013, He was President and Chief Financial Officer of US&S, Inc., a supplier of services and materials to United States government agencies.
“Cleve Christophe’s legendary career makes him one of the most accomplished investors in America,” said David Grain, founder and CEO of Grain. “We look forward to working with him, benefiting from his insights and institutional knowledge, and continuing to invest in and build great companies.”
Christophe’s addition marks the latest expansion of Grain’s board of Senior Advisors, which has now grown to include seven members, each of whom brings specific and differentiated expertise in relevant fields to support Grain’s processes around growth and value creation. Grain’s Senior Advisors work with the Firm’s leadership team and portfolio companies, providing perspectives gained from extensive experience in their fields.
“David Grain and his team take a rigorous, disciplined, data-driven approach to every investment they make, and they have delivered time and again for their investors,” said Christophe. “In a world where communications technology can bring us all closer together, Grain’s work is essential. I am thrilled to help the Firm grow and thrive.”
About Grain Management
Grain Management, LLC is a leading private investment firm that focuses on communications infrastructure and technology companies that connect the world to the information economy. Founded in 2007, the Firm invests exclusively in the telecommunications sector, employing a rigorous, data-based process buoyed by deep industry expertise to identify investment opportunities in key areas of communications infrastructure, including fiber networks, wireless spectrum, and cell towers. For more information visit graingp.com.
Dafna Tapiero


Examining the Historical Role of Businesswomen - Women, Enterprise, and Society
Women have always been a vital part of American economic and business life, yet their contributions have been largely unknown. In 1999, Harvard Business School's Baker Library initiated a survey of the Business Manuscripts Collection to identify materials that recorded women's participation in business. This survey uncovered not only a significant economic record in countless financial and legal documents, it also brought to light unexpectedly rich resources for social and cultural history in a wealth of personal writings. Women, Enterprise & Society records the results of this collection survey.
by Laura Linard, Director of Historical Collections, Baker Library
"[O]ur ladies know nothing of the sober certainties which relate to money," wrote Frederick Tudor in 1820, reflecting a widespread belief that persisted well into the twentieth century. In fact, women have played an integral role in American business and economic history from the very beginning as workers, entrepreneurs, record keepers, business and property owners, and investors.
This contribution was largely invisible as an economic factor, however, during most of the past three centuries. Women's production in the eighteenth and nineteenth centuries was often subsumed under that of the household or defined as non-economic housework. In addition, women entrepreneurs mainly oversaw small and short-lived concerns, which did not fit into traditional analyses of business and commerce.
It is comparatively recently that scholars in a variety of disciplines have begun to discover and interpret historical materials documenting women's lives. When Harvard Business School's Baker Library acquired the majority of its manuscript collections in the first half of the twentieth century, collection guides and catalog records did not describe materials by and about women. In 1999, Baker Library initiated a survey of the Business Manuscripts Collection to identify materials that would be useful to the study of the historical role of women in business and the economy.
This three-year survey uncovered not only a significant economic record in countless financial and legal documents, it also brought to light unexpectedly rich resources for social and cultural history in a wealth of personal writings. Included are manuscript sources, such as account books, credit reports, payrolls, time books, employee registers, letters, and diaries, as well as advertising ephemera and photographs. All of the materials identified by the survey are described in an innovative, Web-based guide entitled Women, Enterprise & Society: A Guide to Resources in the Business Manuscript Collections at Baker Library.
Materials... range from the eighteenth-century accounts of a woman tavern owner from Rhode Island to the nineteenth-century records of a Boston wool merchant.
— Laura Linard
Materials representing the participation of women in the barter economy and in an emerging monetary economy range from the eighteenth-century accounts of a woman tavern owner from Rhode Island to the nineteenth-century records of a Boston wool merchant. The Business Manuscripts Collection is especially rich in records documenting the role of women in the nineteenth-century textile industry, including payrolls and employee registers, as well as labor contracts with women, women's investment records, family records, and information about women's labor activism. There are also materials pertaining to early twentieth-century office practices and the development of human resource and company welfare departments.
Researchers will find legal and investment records documenting women's property ownership and financial management during the last 300 years, from a 1774 document signed by a woman waiving her right of dower to the savvy letters of Ella Lyman Cabot challenging her stockbroker's advice in 1933.
A surprisingly large number of records document eighteenth- and nineteenth-century women's personal lives, such as the diaries of a whaling captain's wife from 1859 to 1860. Advertising ephemera, such as trade and business cards, along with photographic materials help shed light on the growing integration of women in American public life during the late nineteenth and early twentieth century.
When Baker Library initiated this survey project, it was unclear whether any materials relevant to understanding women's role in American industry and the economy would be discovered within the manuscript collections. Three years later, we are very pleased to announce that resources from approximately two hundred collections have been identified and described in this new guide. We invite you to visit the site and encourage you to explore it often. Women, Enterprise & Society is a dynamic resource that will grow and evolve as Baker Library continues to acquire new collections and to identify additional resources for inclusion in the guide.
Evolution of Office Workers
The $100,000.00 Typewriter, exhibited by the Underwood Company at the 1915 Panama-Pacific Exhibition.
The office was an exclusively male domain in the nineteenth century, and "clerk" was the entry position for many young men anxious to rise in business and industry. Late nineteenth-century office mechanization and proliferation of paper work effected a complete gender reversal in the office population. By 1930, the vast majority of office workers were women.
As with other industries, mechanization and female labor brought along devaluation—both monetary and cultural—of skilled labor. Office machines became gender-identified. The postcard reproduced above depicts the 14-ton typewriter the Underwood Company exhibited at the Panama-Pacific Exhibition of 1915. Advertised as "An Exact Reproduction of the Machine You Will Eventually Buy," this machine was "writing daily at the Underwood Exhibit." Sixteen neatly dressed businesswomen, bent over their tasks, seem to be using the giant typewriter (1728x its actual size) as their office.
Exclusively female, twentieth-century office work was no longer a stepping stone to higher echelons in the company. Office work had become an end in itself, and would remain so for most of the twentieth century. Women punched cards, filed, added, typed, and made coffee, and the only stamp they put on the millions of reams of paperwork they produced was a slashed reference found at the bottom of most company letters: ER/cl. By the 1970s, under the influence of the women's movement which decried the dead-end "pink collar ghetto," office workers began to demand pay commensurate with skill, and entry into management level positions.
Reprinted from Women, Enterprise & Society: A Guide to Resources in the Business Manuscript Collections at Baker Library.


Hana Kelly
Album: Two Door Cinema Club – Gameshow
By Hana Kelly
Hana Kelly bids a sad farewell to Two Door Cinema Club’s former glory on their third LP
Released 14th October via Parlophone
Two Door Cinema Club’s newly released album Gameshow has hit the now-metaphorical shelves and it certainly does disappoint. My memory of the unknown tracks being played at Reading Festival this year appeared to be well received by the audience—although, I will admit, I had been drinking. The fun and catchy indie pop/rock of Tourist History and Beacon has long gone. Instead Gameshow is an album of electronic-indie pop tracks that sound like a teenager’s first attempt at mixing a record. Of course evolution as a band is important, and Two Door Cinema Club have definitely evolved, but today I am in mourning for the classics that I will never stop listening to.
Whilst the level of production has clearly increased, the quality has not. The opening of ‘Lavender’ could be a child’s electric drum kit that was set to loop, reminiscent of the joke band ‘The Jerk Offs’ in Nick and Norah’s Infinite Playlist. Meanwhile, listening to the album as a stream is quite an event as the songs fade across into one another, illuminating how cohesive, streamlined, and stylised the album and the band now are.
This triumph is then undermined by the disappearance of Alex Trimble’s fun and characteristic Northern Irish accent that has been replaced with a bland-sounding overmixed voice. His monosyllabic singing is then attached to looped tracks of single drum beats and little reverb. One song, however, that has some memory of their prior glory is the title track, ‘Gameshow’. Trimble’s natural voice can be heard for the most part with the instruments having a much more natural indie feel. However even this track begins to feel uncomfortably simplistic with screeched lyrics towards the crescendo.
I will concede that Two Door Cinema Club are definitely trying something new, and if modernised electronic indie pop/rock is your bread and butter of the music world, then this album could be heaven sent; the album itself peaked at number two on the official album charts and has been mostly well-received. But for me, I’ll just say I’m no longer sad that their Manchester show sold out.
What does a Greggs Sausage Roll have in common with raw meat and indie pop? Matty Healy of course. Check out The Mancunion’s review of the 1975 ‘At Their Very Best’ here.
Ahead of her gig at Manchester Academy, Jessie Reyez talks to The Mancunion about her sudden breakthrough, writing hit songs for other artists, and Latin representation
In conversation with The Murder Capital: “The emotional potency is there, and if anything, it’s stronger now”
The Mancunion speaks to The Murder Capital about life on tour and their much anticipated second album, Gigi’s Recovery
Introducing: The Maddocks
Stockport’s most exciting new export The Maddocks chat to The Mancunion about their new single ‘This Is Why We Can’t Have Nice Things’


Wolf Creek Spins Off 6 Ep TV Series for Pop
by ComicMix Staff · July 28, 2016
LOS ANGELES, CA – July 27, 2016 – Inspired by one of the most terrifying, cult movie franchises ever released in theaters, named one of “The 25 best horror movies since 2000” (AV Squad), one of “The 100 Best Horror films” (Time Out), and one of “The 25 Best Horror Movies Since The Shining” (Vulture), the six-part television event, WOLF CREEK, is a psychological thriller premiering exclusively on Pop on Friday, October 14 at 10:00 PM, ET/PT.
In conjunction with Lionsgate Television and Zodiak Rights (a Banijay Group company), the WOLF CREEK television series on Pop stars John Jarratt, who reprises his movie role as the murdering psychopath Mick Taylor, wreaking havoc in the Australian Outback—except this time, things are different. The television series immediately turns the entire genre on its head when a 19-year-old American college student, played by rising star Lucy Fry, survives the massacre of her parents and little brother and sets out to hunt down the killer and avenge her family.
Based on true events, the original WOLF CREEK movie was introduced in 2005 at the Sundance and Cannes Film Festivals before achieving global box office success and cult film status among horror fans around the world.
“WOLF CREEK is holy !#@$! scary!” said Greg McLean, Executive Producer of the WOLF CREEK television series and the writer, director and producer of the WOLF CREEK movies. “The television series delivers the same pulse-pounding tension and terror of the films combined with a storyline that evolves into a suspense filled, character driven psychological thriller. In many ways, WOLF CREEK is more like a Western—set in the untamed, desolate landscape of the Australian Outback, with gritty characters and an immersive story of revenge and good versus evil.”
“WOLF CREEK is a binge-worthy, premium revenge tale that we are thrilled to bring fans at the perfect time of the year,” said Brad Schwartz, President, Pop. “To turn everything you expect from a horror film around and hunt the psychopath through a strong and singularly-focused female protagonist is thrilling to watch. It is probably the scariest series to ever premiere on basic cable and will have viewers hooked 13:40 minutes into the first episode.”
The story of WOLF CREEK begins when an American family is on holiday in Northern Australia and becomes the unsuspecting prey of Mick Taylor, a sadistic serial killer who hunts and kills tourists in the Outback. The sole survivor is Eve Thorogood, a college student, who vows to bring the killer to justice or die in the attempt. The story of WOLF CREEK reveals her complex and extraordinary journey, traveling every step of the way as she evolves from child to adult, from prey to predator. But can she triumph over Mick Taylor, evil incarnate?
John Jarratt is a television and film actor, producer and director from Australia. Jarratt is best known for his chilling performance as the iconic character Mick Taylor in the feature films Wolf Creek and Wolf Creek 2. His previous credits also include Peter Weir’s Picnic At Hanging Rock, Baz Luhrmann’s Australia and Quentin Tarantino’s Django Unchained.
Lucy Fry is a film and television actress. Most recently, Fry starred opposite James Franco in the Warner Bros. for Hulu mini-series “11.22.63.” She is also known for her roles in director Joseph Castelo’s indie film The Preppie Connection and Mark Waters’ fantasy feature Vampire Academy.
A STAN original, WOLF CREEK is produced by Screentime (a Banijay Group company), in association with Emu Creek Pictures and financed with the assistance of Screen Australia and the South Australian Film Corporation.
Next story Martha Thomases’ It’s a Wonderful Life
Previous story Tweeks: Voltron Legendary Defender SDCC Interviews


Imagine buying a factory-fresh Lamborghini, parking it, and then never driving it for decades.
That’s essentially what the owner, or in this case owners, of this 1990 Lamborghini Countach 25th Anniversary Edition did. (It also happened to a McLaren F1, which seems even crazier.)
The car, which bears chassis number ZA9CA05A7LLA12718, has just 249 kilometers (approximately 155 miles) on its odometer. It also has its original Pirelli P Zero tires, which by now will be too dangerous to drive on at speed.
The mileage figure is a little more than the delivery miles, according to a listing at auction house RM Sotheby’s, which will put the car under the hammer on Jan. 26 at its sale in Phoenix, Arizona. An original bill of sale shows the car was delivered to its first owner in 1990 with just 138 kilometers (82 miles). The price paid was $275,000.
1990 Lamborghini Countach 25th Anniversary Edition – Photo credit: RM Sotheby’s
That first owner kept the car for 17 years, during which just 13 kilometers (8 miles) were added. It was returned to its original dealership in 2007, in this case Clark Motor Company of Heath, Ohio, and was later kept in a collection between 2010 and 2020, during which it experienced only short drives to keep everything working. The current seller bought it in 2020.
Considering the remarkable condition and low mileage, perhaps the lowest of any Countach, the car is sure to attract plenty of attention at its upcoming sale. RM Sotheby’s has estimated a final bid of between $750,000 and $1 million.
The 25th Anniversary Edition, as the name suggests, was built to celebrate 25 years of Lamborghini. It’s distinguished by its unique spoilers and modified air vents, some of which were designed by Pagani CEO and founder Horacio Pagani, when he was still working for Lamborghini.
Drive comes from a 5.2-liter V-12 delivering 455 hp and capable of carrying the car to a top speed of 183 mph. The tires fitted were the widest fitted to any production car of its time, measuring 225/50 at the front and 345/35 at the rear.
Icon FJ43 Bandeirante reimagines a timeless classic
Mercedes F1 chief’s Ferrari F40 up for sale
First Mercedes-Benz AMG One customer car is delivered


First-place Sixers square off against NBA-best Suns to conclude road trip
By Sean Kennedy@PhillyFastBreak Mar 27, 2022, 7:00am EDT
Share All sharing options for: First-place Sixers square off against NBA-best Suns to conclude road trip
The Sixers have a chance tonight to sweep their three-game West Coast road trip, but they’ll have a much tougher obstacle in front of them than injury-riddled Lakers and Clippers clubs. The Phoenix Suns sit at 60-14, far and away the best record in the NBA. They are currently riding a seven-game winning streak, most recently sweeping a three-game road trip of their own, defeating Sacramento, Minnesota, and Denver. More crucially for Phoenix, Chris Paul returned to the court in the win over the Nuggets after missing just over a month due to a fractured thumb. CP3 did not look the least bit affected by the layoff, tallying 17 points and 13 assists in 30 minutes.
In the earlier meeting between these two teams back in February, the Suns prevailed, 114-109, led by Devin Booker’s 35 points. Booker is in the midst of a hot stretch at the moment, averaging 30.4 points per game in the month of March, including 49 points on Thursday on the five-year anniversary of his 70-point game. The matchup of Matisse Thybulle on Booker will surely be one to watch.
While the Suns have impressively already clinched the top seed in the Western Conference, the Sixers are in the throes of a tightly-contest mix near the top of the East. Following last night’s results, the Sixers are tied for first place in the conference with Philadelphia, Miami, Boston, and Milwaukee are all within one half-game of each other. As our Tariq Karibian laid out in an article yesterday, there are a lot of factors in how the Sixers approach the home stretch of this regular season, from injury and load management to the possibility of a lower seed meaning an easier first-round matchup against Chicago or Cleveland (although I would note the Raptors are surging up the standings and that would be a very difficult series). Whatever happens, being tied for first place right now given the Ben Simmons-sized hole in the roster for more than half the season is quite remarkable.
Regardless, we are probably a week or so away from the Sixers starting to think about such things seriously and there is no back-to-back consideration for tonight’s outing. Expect all hands on deck in a measuring stick game against a Suns team at nearly full strength, the primary exception being the absence of promising third-year wing Cameron Johnson, out with a quad injury. Tonight is an excellent opportunity for the Sixers to see how they stack up against the odds-on favorite to win the title this season. In addition to witnessing a highly competitive matchup, local Sixers fans are no doubt thrilled at the 6:00pm start time after the last two night owl performances. Enjoy tonight’s contest and check back with us at Liberty Ballers to follow along with the action.
Who: Philadelphia 76ers vs. Phoenix Suns
When: 6:00 pm ET
Where: Footprint Center, Phoenix, AZ
Watch: NBC Sports Philadelphia
Radio: 97.5 The Fanatic
Follow: @Liberty_Ballers


Man United chief Ed Woodward’s private opinion on sacking Ole Gunnar Solskjaer amid poor form
October 19, 2021 Idu Football, News 0
Manchester United’s executive vice-chairman Ed Woodward is confident that Ole Gunnar Solskjaer will turn the club’s form around over the coming weeks and months, according to reports.
The Red Devils boss currently finds himself under plenty of external pressure to put things right after a shaky start to the new Premier League campaign.
United currently sit outside the division’s top five, with Solskjaer’s side occupying sixth place after winning just four of their eight fixtures so far this season.
The Red Devils have only managed one victory from their last four outings in all competitions and will face an incredibly tough run of fixtures over the next few weeks.
Atalanta will be their next opponents in the Champions League on Wednesday evening before Liverpool visit Old Trafford on Sunday afternoon.
United will also go up against Tottenham, Atalanta once again and Manchester City between now and the November international break.
The club’s lack of recent form has led to calls for Solskjaer, who signed a long-term contract extension back in July, to be relieved of his duties.
However, it seems as though Woodward is determined to stand by his man and give him every chance to deliver a positive reaction before the end of the season.
The United chief and his fellow directors have privately backed Solskjaer to succeed and have ruled out the possibility of pulling the trigger in the near future, according to the Daily Star.
The report claims that Solskjaer will keep his job even if United fail to resurrect their form over the coming weeks.
He was heavily supported by the board over the summer months, with the likes of Raphael Varane and Jadon Sancho joining United in big-money moves before the deadline.
The Red Devils also managed to successfully bring Cristiano Ronaldo back to Manchester on a lucrative two-year contract with the option of a third on the final day of the window.
United director John Murtough recently underlined his desire to keep Solskjaer at the helm, insisting that the club’s decision-makers will not be swayed by the frustration of supporters on social media.
“[We] need to keep control, don’t get carried away, don’t deviate from our plan,” Murtough told a fans’ forum last month.
“Ole and the staff are very focused on that. We have a long-term strategy and confidence in the direction that we’re going.
“We believe that we’ve got the talent and the character within the squad to succeed. The Premier League is one of the most competitive leagues in the world.
“Players from abroad and other leagues tell us how [challenging] it is, but we are 100 per cent up for that.
“[We] don’t get distracted by what’s said on social media, which can sometimes create fervour and hysteria.
“It’s part of the modern game, but we stay focused.”
Man United’s view on sacking Ole Gunnar Solskjaer if they lose to Liverpool and Man City
Antonio Conte trend highlights demand he would make to Man United board


A Study of WebRTC Security
程序员艳庆 技术 2022年11月23日
0 收藏 315 点赞 4,548 浏览 43534 个字
转自：http://webrtc-security.github.io/
Web Real-Time Communication (abbreviated as WebRTC) is a recent trend in web application technology, which promises the ability to enable realtime communication in the browser without the need for plug-ins or other requirements. However, the open-source nature of the technology may have the potential to cause security-related concerns to potential adopters of the technology. This paper will discuss in detail the security of WebRTC, with the aim of demonstrating the comparative security of the technology.
WebRTC is an open-source web-based application technology, which allows users to send real-time media without the need for installing plugins. Using a suitable browser can enable a user to call another party simply by browsing to the relevant webpage.
Some of the main use cases of this technology include the following:
Real-time audio and/or video calls
Direct data transfers
Unlike most real-time systems (e.g. SIP), WebRTC communications are directly controlled by some Web server, via a JavaScript API.
The prospect of enabling embedded audio and visual communication in a browser without plugins is exciting. However this naturally raises concerns over the security of such technology, and whether it can be trusted to provide reliable communication for both the end users and any intermediary carriers or third parties.
This report will address these topics and examine the protections that WebRTC provides to provide security in all cases. For the purposes of this paper however, native applications will be treated as being out of scope.
2. Overview of WebRTC Architecture
WebRTC enables direct media-rich communication between two peers, using a peer-to-peer (P2P) topology. WebRTC resides within the user’s browser, and requires no additional software to operate. The actual communication between peers is prefaced by an exchange of metadata, termed “signalling”. This process is used to initiate and advertise calls, and facilitates connection establishment between unfamiliar parties.
As depicted in Figure 1, this process occurs through an intermediary server:
Figure 1. A simple WebRTC Call Topology
A signaling protocol is not specified within WebRTC, allowing developers to implement their own choice of protocol. This allows for a deeper degree of flexibility in adapting a WebRTC app for a specific usecase or scenario.
How does WebRTC communication work?
WebRTC relies on three APIs, each of which performs a specific function in order to enable real-time communication within a web application. These APIs will be named and explained briefly. The implementation and technical details of each protocol and technology are outside the scope of this report, however the relevant documentation is readily available online.
For many years it was necessary to rely on third-party browser plugins such as Flash or Silverlight to capture audio or video from a computer. However, the era of HTML 5 has ushered in direct hardware access to numerous devices, and provides JavaScript APIs which interface with a system’s underlying hardware capabilities.
getUserMedia is one such API, enabling a browser to access a user’s camera and microphone. Although utilised by WebRTC, this API is actually offered as part of HTML 5.
RTCPeerConnection is the first of two APIs which are offered specifically as part of the WebRTC specification. A RTCPeerConnection interface represents the actual WebRTC connection, and is relied upon to handle the efficient streaming of data between two peers.
When a caller wants to initiate a connection with a remote party, the browser starts by instantiating a RTCPeerConnection object. This includes a self-generated SDP description to exchange with their peer. The recipient in turn responds with it’s own SDP description. The SDP descriptions are used as part of the full ICE workflow for NAT traversal.
With the connection now established, RTCPeerConnection enables the sending of real-time audio and video data as a bitstream between browsers.
Ultimately, RTCPeerConnection API is responsible for managing the full life-cycle of each peer-to-peer connection and encapsulates all the connection setup, management, and state within a single easy-to-use interface.
RTCPeerConnection has two specific traits: – Direct peer-to-Peer communication between two browsers – Use of UDP/IP – there is no guarantee of packet arrival (as in TCP/IP), but there is much reduced overhead as a result. – (By allowing the loss of some data, we can focus upon offering real-time communication.)
References: [1] [2]
The RTCDataChannel is the second main API offered as part of WebRTC, and represents the main communication channel through which the exchange of arbitrary application data occurs between peers. In other words, it is used to transfer data directly from one peer to another.
Although a number of alternative options for communication channels exist (e.g. WebScoket, Server Sent Events), however these alternatives were designed for communication with a server rather than a directly-connected peer. RTCDataChannel resembles the popular WebSocket, but instead takes a peer-to-peer format while offering customisable delivery properties of the underlying transport.
2.1. Underlying Technologies
The three main APIs are the developer-facing aspects of WebRTC, but there are a number of foundational technologies which are utilised in order to provide these protocols (the RTCPeerConnection and RTCDataChannel APIs).
Figure 2. WebRTC Protocol Stack
ICE, STUN, and TURN are necessary to establish and maintain a peer-to-peer connection over UDP. DTLS is used to secure all data transfers between peers, as encryption is a mandatory feature of WebRTC. Finally, SCTP and SRTP are the application protocols used to multiplex the different streams, provide congestion and flow control, and provide partially reliable delivery and other additional services on top of UDP.
SDP: Session Description Protocol
Session Description Protocol (SDP) is a descriptive protocol that is used as a standard method of announcing and managing session invitations, as well as performing other initiation tasks for multimedia sessions. SDP represents the browser capabilities and preferences in a text-based format, and may include the following information: – Media capabilities (video, audio) and the employed codecs – IP address and port number – P2P data transmission protocol (WebRTC uses SecureRTP) – Bandwidth usable for communication – Session attributes (name, identifier, time active, etc.) -> However these are not used in WebRTC. – Other related metadata…
As of today SDP is widely used in the contexts of Session Initiation Protocol (SIP), Real-time Transport Protocol (RTP), and Real-time Streaming Protocol (RSP).
References: [3]
ICE: Interactive Connectivity Establishment
Signalling requires the initial use of an intermediary server for the exchange of metadata, but upon completion WebRTC attempts to establish a direct P2P connection between the users. This process is carried out through the ICE framework.
ICE is a framework used for establishing a connection between peers over the internet. Although WebRTC tries to utilise direct P2P connections, in reality the widespread presence of NAT (Network Address Translation) makes it difficult to negotiate how two peers will communicate.
Due the continuing widespread prevailence of IPv4 addresses with their limited 32-bit representation, most network-enabled devices do not have a unique public-facing IPv4 address with which it would be directly visible on the Internet. NAT works by dynamically translating private addresses into a public ones when an outbound request passes through them. Similarly, inbound requests to a public IP are converted back into a private IP to ensure correct routing on the internal network. Resultantly, sharing a private IP is often not enough information to establish a connection to a peer. ICE attempts to overcome the difficulties posed by communicating via NAT to find the best path to connect peers.
By trying all possibilities in parallel, ICE is able to choose the most efficient option that works. ICE first tries to make a connection using the host address obtained from a device’s operating system and network card; if that fails (which it inevitably will for devices behind NATs) ICE then obtains an external address using a STUN server. If that also fails, traffic falls back to routing via a TURN relay server.
The candidate communication routes are rendered in a text-based format, and the list ordered by priority. The options take the form of one of the following: – Direct P2P communication – Using STUN, with a port mapping for NAT traversal (This route eventually resolves to direct P2P communication) – Using TURN as an intermediary (this configuration employs relayed communication rather than P2P)
Out of all posssible candidates, the route with the smallest overhead is chosen.
STUN: Session Traversal Utilities for NAT
In order to perform P2P communication, both parties necessarily require at least the knowledge of their peer’s IP address and the assigned UDP port. As a result, a certain amount of information exchange is necessary before WebRTC communication can be established.
A STUN server is used by each peer to determine their public IP address, and is referenced by the ICE framework during connection establishment. STUN servers are typically publically accessible, and can be used freely by WebRTC applications.
TURN: Traversal Using Relays around NAT
In the eventuality that establishing a P2P communication fails, a fallback option can be provided via a TURN server. By relaying traffic between peers the WebRTC communication can be ensured, but can suffer degregations in media quality and latency.
TURN servers can ensure high success in setting up calls, regardless of the end-user’s environments. As the data is sent through an intermediary server, server bandwidth is also consumed. If many calls are simulataneously routed through the server, the bandwidth was also become considerable in size.
The server itself is typically not freely accessible, and has to be specifically provided (or rented) by the application provider.
3. Browser-based Security Considerations
There are a number of ways in that a real-time communication application may impose security risks, both on the carrier and the end users. Such security risks can be applicable to any application which deals with the transmission of real-time data and media.
WebRTC differs from other RTC apps by providing a strong and reliable infrastructure for even new developers to utilise without compromising on security. We will now proceed to discuss how WebRTC deals with each of these risks in turn.
3.1. Browser Trust Model
The WebRTC architecture assumes from a security perspective that network resources exist in a hierarchy of trust. From the user’s perspective, the browser (or user client) is basis of all WebRTC security, and acts as their Trusted Computing Base (TCB).
The browser’s job is to enable access to the internet, while providing adequate security protections to the user. The security requirements of WebRTC are built directly upon this requirement; the browser is the portal through which the user accesses all WebRTC applications and content.
While HTML and JS provided by the server can cause the browser to execute a variety of actions, the browser segregates those scripts into sandboxes. Said sandboxes isolate scripts from each other, and from the user’s computer. Generally speaking, scripts are only allowed to interact with resources from the same domain – or more specifically, the same “origin”.
The browser enforces all security policies that the user desires and is the first step in the verification of all third parties. All authenticated entities have their identity checked by the browser.
If the user chooses a suitable browser which they know can trust, then all WebRTC communication can be considered “secure” and to follow the standard accepted security architecture of WebRTC technology. However, if there is any doubt that a browser is “trustable” (e.g. having been downloaded from a third party rather than a trusted location), then all following interaction with WebRTC applications is impacted and may not be reliably secure.
In other words, the level of trust provided to the user by WebRTC is directly influenced by the user’s trust in the browser.
3.2. SOP: Same Origin Policy
It is a fundamental aspect of the DOM that all webpage resources are fetched from the page’s web server, whenever some or all of the page is loaded. Fetching of resources takes place either when a page is freshly loaded by the browser, or when a script residing on a webpage makes such a request. Such scripts are readily able to make HTTP requests via e.g. the XMLHttpRequest() API, but are not permitted to make such requests to just any server they specify. Rather, requests have to be made to the same “origin” from where the script originated. An “origin” comprises of a URI scheme, hostname, and port number. This overall restrication is termed the “Same Origin Policy” (SOP).
SOP forces scripts to execute in isolated sandboxes specific to their originating domain, therefore preventing pages from different origins or even iframes on the same page from exchanging information. Webpages and scripts from the same origin server remain unhindered in interacting with each other’s JS variables. As such, the origin constitutes the basic unit of web sandboxing.
Through enforcing execution sandboxes on a per-origin basis, the end user is protected from the misuse of their credentials. You would reasonably expect to safely use a social networking website without a script executing from within an advertisement panel and stealing your login information.
Similarly, the servers of e.g the webpage provider are protected from attacks mounted via the user’s browser; If such safeguards did not exist, DoS attacks could otherwise be launched through abusive resource requests.
3.2.1 Bypassing SOP
SOP is incredibly important for the security of both the user and web servers in general, although it does have the disadvantage of making certain types of web app harder to create. Methods of permitting inter-site interaction do exist, although these are typically mutually consensual and limited to certain channels.
The W3C Cross-Origin Resource Sharing (CORS) spec is one of the answers to the problem. It allows the browser to contact the script’s target server to determine whether it is willing to participate in a given type of transaction. As such, cross-origin requests can be safely allowed, by giving the target server the option to specifically opt-in to certain requests and decline all others.
WebSockets is another option allowing similar functionality, but on transparent channels rather than isolated HTTP requests. Once such a connection has been established, the script can transfer traffic and resources as it likes, with the necessity of framing as a series of HTTP request/response transactions.
In both cases, the initial verification stage prevents the arbitrary transfer of data by a script with a different origin.
4. WebRTC Security Considerations
4.1. Installation and Updates
A prevalent issue with traditional desktop software is whether one can trust the application itself. Installation of new software or a plugin can potentially surruptiously install malware or other undesirable software. Many end users have no idea where the software was made or exactly who they are downloading the app from. Malicious third parties have had great success in repackaging perfectly safe and trusted software to include malware, and offering their custom package on free software websites.
WebRTC however is not a plugin, nor is there any installation process for any of its components. All the underlying WebRTC technology is installed simply as part of downloading a suitable WebRTC-compatible browser, such as Chrome or Firefox. If a user has such a browser, they can browse to and use any WebRTC application with no other setup or preparation required. As such there is no risk of installation of malware or viruses through the use of an appropriate WebRTC application. However, WebRTC apps should still be accessed via a HTTPS website signed by a valid authenticator such as Verisign.
Another related consideration is the patching of discovered security flaws in software. As with any software technology, it is entirely possible that future bugs or vulnerabilities will be discovered in WebRTC. If a vulnerability is found in an traditional desktop application (such as a typical VoIP application), development of a patch may take considerable time. This is a frequent issue with application development, as security is still often treated as a secondary consideration after functionality. Going deeper than this, we can contemplate hardware-based communication methods. How often does a VoIP phone get a security update? Can you trust the person responsible to update it regularly? Do you even know who is responsible?
Contrary to this, browsers are a fast-paced development scene due to the frequency and range of risks users are exposed to, as well as their ubiquitous nature (and the importance of information accessed through the browser). As WebRTC’s components are offered as part of a browser, they are likewise updated whenever the browser is updated. If a future vulnerability were to be found in a browser’s WebRTC implementation, a fix will likely be delivered rapdily. This can particularly be seen to be true in Chrome and Firefox’s rapid development cycles. In fact, in the era of automatic updates, WebRTC components can be updated through a new browser version as soon as the patch is made available on servers. Most modern browsers have a good record of auto-updating themselves within 24 hours of the discovery of a serious vulnerability or threat.
As a side note: Although we have stated that WebRTC requires no plugins to be installed, it is possible that third-party WebRTC frameworks may offer plugins to enable support on currently unsupported browsers (such as Safari and IE). User caution (or a supported browser) is recommended in such instances.
4.2. Access to Media/Local resources
The browser can access local resources (including camera, mic, files), which leads the inevitable concern of a web application accessing a user’s microphone and camera. If web applications could freely gain access to a user’s camera or microphone, an unscrupulous app may attempt to record or distribute video or audio feeds without the user’s knowledge. It could be a simple matter for a website residing in a background tab to abuse the user’s trust (the user may not even realise a site harbours such a communication application).
WebRTC combats this by requiring the user to give explicit permission for the camera or microphone to be used (both can be configured indivudally). It is possible to ask the user for one-time or permanent access. It is not possible for a WebRTC application to arbitrarily gain access or operate either device. Furthermore, when either the microphone or camera is being used the client UI is required to expressly show the user that the microphone or camera are being operated. In Chrome, this takes the form of a red dot on any tab accessing a user’s media.
Figure 3. Chrome UI Indicators
The philosophy of this security protection is that a user should always be making an informed decision on whether they should permit a call to take place, or to receive a call. In other words, a user must understand: – Who or what is requesting access to his media – Where the media is going – Or both.
As an additional provision, the WebRTC spec specifies that browsers SHOULD stop the camera and microphone when the UI indicator is masked (e.g. by window overlap). Although this is more of an ideal behaviour, it isn’t necessarily guarenteed and users should exercise caution. Fortunately however, this additional functionality is not likely to be behaviour expected by the user.
Screen sharing introduces further security considerations due to the inherent flexibility of scope. A user may not be immediately aware of the extent of the information that they are sharing. For instance, they may believe they are simply sharing a stream of a particular window (e.g. while giving a presentation to remote parties), when in reality they are showing their entire screen to their audience. This may be a result of the user failing to correctly establish the initial screen sharing setup, or else that the user may simply forget the extent of what they are sharing.
4.3. Media Encryption & Communication Security
There are a number of ways in that a real-time communication application may impose security risks. One particularly notable one is the interception of unencrypted media or data during transmission. This can occur between browser-browser or browser-server communication, with an eavesdropping third-party able to see all data sent. Encryption however, renders it effectively impossible for an eavesdropper to determine the contents of communication streams. Only parties with access to the secret encryption key can decode the communication streams.
Encryption is a mandatory feature of WebRTC, and is enforced on all components, including signaling mechanisms. Resultantly, all media streams sent over WebRTC are securely encrypted, enacted through standardised and well-known encryption protocols. The encryption protocol used depends on the channel type; data streams are encrypted using Datagram Transport Layer Security (DTLS) and media streams are encrypted using Secure Real-time Transport Protocol (SRTP).
4.3.1. DTLS: Datagram Transport Layer Security
WebRTC encrypts information (specifically data channels) using Datagram Transport Layer Security (DTLS). All data sent over RTCDataChannel is secured using DTLS.
DTLS is a standardised protocol which is built into all browsers that support WebRTC, and is one protocol consistently used in web browsers, email, and VoIP platforms to encrypt information. The built-in nature also means that no prior setup is required before use. As with other encryption protocols it is designed to prevent eavesdropping and information tampering. DTLS itself is modelled upon the stream-orientated TLS, a protocol which offers full encryption with asymmetric cryptography methods, data authentication, and message authentication. TLS is the de-facto standard for web encryption, utilised for the purposes of such protocols as HTTPS. TLS is designed for the reliable transport mechanism of TCP, but VoIP apps (and games etc) typically utilise unreliable datagram transports such as UDP.
As DTLS is a derivative of SSL, all data is known to be as secure as using any standard SSL based connection. In fact, WebRTC data can be secured via any standard SSL based connection on the web, allowing WebRTC to offer end-to-end encryption between peers with almost any server arrangement.
4.3.1.1. DTLS over TURN
The default option for all WebRTC communication is direct P2P communication between two browsers, aided with signalling servers during the setup phase. P2P encryption is relatively easy to envisage and setup, but in the case of failure WebRTC setup falls back to communication via a TURN server (if available). During TURN communication the media can suffer a loss of quality and increased latency, but it allows an “if all else fails” scenario to permit WebRTC application to work even under challenging circumstances. We must also consider encrypted communication under TURN’s alternative communication structure.
It is known that regardless of communication method, the sent data is encrypted at the end points. A TURN server’s purpose is simply the relay of WebRTC data between parties in a call, and will only parse the UDP layer of a WebRTC packet for routing purposes. Servers will not decode the application data layer in order to route packets, and therefore we know that they do not (and can not) touch the DTLS encryption.
Resultantly, the protections put in place through encryption are therefore not compromised during WebRTC communication over TURN, and the server cannot understand or modify information that peers send to each other.
4.3.2. SRTP: Secure Real-time Transport Protocol
Basic RTP does not have any built-in security mechanisms, and thus places no protections of the confidentiality of transmitted data. External mechanisms are instead relied on to provide encryption. In fact, the use of unencrypted RTP is explicitly forbidden by the WebRTC specification.
WebRTC utilises SRTP for the encryption of mediastreams, rather than DTLS. This is because SRTP is a lighter-weight option than DTLS. The specification requires that any compliant WebRTC implementation support RTP/SAVPF (which is built on top of RTP/SAVP) [9]. However, the actual SRTP key exchange is inially performed end-to-end with DTLS-SRTP, allowing for the detection of any MiTM attacks.
4.3.3. Establishment of a secure link
Let us step through the process of establishing a new call on a WebRTC application. In this instance, there will be two parties involved; Alice and Bob. The call procedure is initiated when one party (Alice) calls the other (Bob), and the signalling process exchanges the revelant metadata between both parties.
Once the initial ICE checks have concluded (or specifically, some of them), the two peers will start to setup one or more secure channels. Initially, a DTLS handshake is performed on all channels that are established by ICE. For the data channels, this step alone is sufficient as plain simple DTLS is used for encryption. For the media channels however, further steps are taken.
Once the DTLS handshake completes, the keys are “exported” and used to key SRTP for the media channels. At this stage both parties know that they share a set of secure data and/or media channels with keys which are not known to any malicious third-party.
References: [10]
4.3.4. DTLS-SRTP vs SDES
In order to negotiate the security parameters for the media traffic session, SRTP needs to interact with a key management protocol. This protocol is not established, offering up a number of possible options for the task. Two such options ares SDES and DTLS-SRTP.
It is worth noting that the signalling (SIP, HTTP) & media (RTP) involved in a multimedia communication can be secured independently.
SDP Security Descriptions for Media Streams (SDES) was the option previously favoured by WebRTC.
Within SDES, the security parameters and keys used to set up SRTP sessions are exchanged in clear text in the form of SDP attributes. As SDP is communicated over the signalling plane, if encryption is not additionally enacted upon such signalling messages then an eavesdropping third party could obtain the keys for the SDES encrypted data. In other words, a further encrpytion protocol should be utilised specifically for the encryption of the signalling plane. One such option for this is to use TLS.
Securing the signalling and media independently however, can lead to the situation in that the media user is different from the signalling user (as no guarentee is provided). To provide this guarentee, a cryptographic binding is necessary. DTLS-SRTP is one such mechanism that provides this, but SDES does not.
It remains a fact that even today, the majority of RTP traffic in VoIP networks is not secured. In fact, encyption is one of the very first features customers usually ask vendors to remove in order to meet their budgets. When secured, most of the deployments utilise SDES, which as we just mentioned relies heavily on signalling plane security.
DTLS-SRTP
DTLS-SRTP on the other hand exchanges keys over the media plane, rather than the signalling plane. The consequence of such a difference is that an SRTP media channel has no need to reveal the secret encryption keys through an SDP message exchange, as is the case with SDES.
The WebRTC specification [9] asserts that WebRTC implementations are required to support DTLS-SRTP for key management. Moreover, it is specified to be the default and preferred scheme, and there is no provision for other key management schemes to be implemented. In other words, other schemes may or may not be supported at all.
If an offer or “call” is received from a peer advertising support for both DTLS-SRTP and SDES, DTLS-SRTP must be selected – irrespective of whether the signalling is secured or not.
It is generally accepted that DTLS-SRTP should be the madatory and default option for the encryption of WebRTC media. What is being questioned is whether other mechanisms, namely SDES, should be utilised to provide backward compatability.
From the compatibility persepctive, Google’s Chrome browser provides support for both SDES and DTLS-SRTP. Mozilla’s Firefox on the other hand only implementes DTLS-SRTP.
References: [11] [12]
4.3.5. A Weakness in SRTP
SRTP only encrypts the payload of RTP packets, providing no encryption for the header. However, the header contains a variety of information which may be desirable to keep secret.
One such piece of information included in the RTP header is the audio-levels of the contained media data. Effectively, anyone anyone who can see the SRTP packets can tell whether a user is speaking or not at any given time. Although the contents of the media itself remains secret to any eavesdropper, this is still a scary prospect. For example, Law enforcement officals could determine whether a user is communicating with a known badguy.
4.4. Web-Based Peer Authentication & Identity Management
It is desirable for a user to be able to verify the identify of their peers. I.e. a user naturally wants to be certain that they are speaking to the person they believe that they are speaking to, and not an imposter.
Although the signalling server may be able to go some way towards claiming a user’s identity, the signalling server itself may not (and for the case of authentication SHOULD not) be trusted. We need to be able to perform authentication of our peers independently from the signalling server. This can be made possible through the use of identity providers.
Figure 4. A call with IdP-based identity
A number of web-based identity providers (IdP) have recently become commonplace on the web, including Facebook Connect, BrowserID (by Mozilla), OAuth (by Twitter). The purpose of these mechanisms is simply to verify your identity to other services/users, on the authority of the identity provider itself. If a user has an account on Facebook then they can then use Facebook Connect, Facebook’s IdP to prove to others that the are who they say they are on Facebook. This allows users to tie their authentication on other services to their main account on a “trusted” service. Note that in this case the level of “trust” that an Identity Provider possesses is subjective to the end-point user or service, and is often largely tied to userbase and reputation across the World Wide Web.
The implementations of each IdP may differ due to independent development by different companies rather than being based on an open-source standard, but the underlying principle and functionality remains essentially the same. IdPs do not provide authentication for a signalling server; rather, they provide authentication for a user (and their browser through the process). WebRTC also places no requirements on which services should be used, and those which are utilised are based on the web application’s implementation.
As the web application (calling site) is unrelated to this authentication process, it is important that the browser securely generates the input to the authentication process, and also securely displays the output on the web application. This process must not be able to be falisified or misrepresented by the web application.
Figure 5. The operation of an Identity Provider
4.5. IP Location Privacy
One adverse side-affect of using ICE is that a peer can learn one’s IP address. As IP addresses are publicly registered with global authorities, they can reveal such details as a given peer’s location. This could naturally have negative implications for a peer, which they would wish to avoid.
WebRTC is not designed with the intention of protecting a user from a malicious website which wants to learn this information. Typically, such a site will learn at least a user’s server reflexive address from any HTTP transaction. Hiding the IP address from the server would require some kind of explicit privacy preserving mechanism on the client, and is out of scope of this report.
WebRTC does however provide a number of mechanisms which are intended to allow a web application to cooperate with the user to hide the user’s IP address from the other side of the call. These mechanisms will be detailed in turn.
A WebRTC implementation is required to provide a mechanism to allow JS to suppress ICE negotiation until user has decided to answer the call. This provision assists end users in preventing a peer from learning their IP address if they elect not to answer a call. This has the side affect of hiding whether a user is online or not to their peers.
The second such provision is that any implementation will provide a mechanism for the calling app’s javascript to indicate that only TURN candidates are to be used. This can prevent a peer from learning one’s IP address at all.
Furthermore, there is a mechanism for the calling app to reconfigure an existing call to add non-TURN candidates. Taken together with the previous provision, this allows ICE negotiation to start immediately upon an incoming call notification, thereby reducing delay, but also avoiding disclosing the user’s IP address until they have decided to answer. This allows users to completely hide their IP address for the duration of the call.
4.6. Signalling Layer
As the signalling protocol is not specified by WebRTC, the mechanism for encryption obviously depends on the signalling protocol chosen. Due to the relatively open nature of signalling security, this report will focus on and briefly explain the of the most common protocol, SIP (Session Initiation Protocol).
SIP is a widely implemented standard used in VoIP communication to setup and tear down phone calls. However, it is a derivative of HTTP and SMTP – both are protocols that are regularly exploited. As it uses plain-text messages to exchange information, it is feasbile for any malicious party to tap a network and capture SIP messages. If an attacker can read a user’s sensitive information, they could use this information to spoof the user. And if the attacker can further proceed to gain access to the operator’s network, it can even be possible for them to decipher the contents of WebRTC communication.[14]
Since SIP is sent in clear text, it is trivial for a determined attacker to intercept SIP messages. What happens next is left up to the imagination of the attacker, but it is not hard to imagine an eventuality in that the contents of the message body or header is tampered with. If the attacker intercepts an INVITE message, they may then proceed to change the FROM header to reflect his or her own IP address.
4.6.1. SIP Vulnerabilities
SIP is a communications protocol for signalling and controlling multimedia communication sessions and is frequently implemented in VoIP technologies for the purposes of setting up and tearing down phone calls. It can similarly be used in a WebRTC implementation for signalling purposes, as one of a number of possible such options. However, SIP messages are frequently sent in plain text. As this can naturally result in a number of potential attack vectors, we will take a closer examination of this area.
SIP Flow
In the process of setting up a call, a user’s browser (or “User Agent”) registers with a central registrar. This registration is a necessity in traditional VoIP as it is necessary to provide the means to locate and contact a remote party.
When a party (Bob) wants to initiate a call, he sends an INVITE message via a central proxy server (this is the signalling server). The server is responsible for relaying such messsages, and providing the means to locate other users. The server may attempt a number of measures to locate a end-user during this lookup process, such as utilising DNS.
Registration Hijacking
The initial browser registration is used to announce a user’s point of contact, and indicates that a user’s device is accepting calls. However the process provides a vector for malicious entities to perform a “Registration Hijack” attack.
The exchange of registration messages includes a “Contact:” field, containing the user’s IP address. Whenever the signalling server processes an incoming call, the user name (or phone number) is matched up with the registered IP address, and the INVITE is forwarded accordingly. These registrations are periodically updated, ensuring the records are kept recent and up to date.
As SIP messages are always sent in plain text, it can be trivial for an attacker to intercept and read the contents of these registration messages. Following the interception, an appropriate tool (such as SiVuS Message generator) can be used to generate similar SIP information, but with the user’s true IP address replaced by the attacker’s own. The attacker then only has to disable the real user and send this information periodically to divert all incoming calls to themselves.
There are a number of methods that an attacker could utilise to disable a legitimate user, including: – Performing a DoS attack against the user’s device – Deregistering the user (another attack which is not covered here) – Generating a registration race-condition, in which the attacker sends repeatedly REGISTER requests in a shorter timeframe (such as every 15 seconds) in order to override the legitimate user’s registration request. This are all genuine risks to WebRTC signalling services.
As the implementation of SIP does not support the checking integrity of the message contents, modification and replay attacks are therefore not detected and are a feasible attack vector. This attack works even if the server requires authentication of user registration, as the attacker can once again capture, modify and replay messages as desired.
This attack can be suppressed by implementing SIPS (SIP over TLS) and authenticating SIP requests and responses (which can include integrity protection). In fact, the use of SIPS and the authentication of responses can suppress many associated attacks including eavesdropping and message or user impersonation.
Other possible attacks
MiTM attack
If the attacker is able to intercept the initial SIP messages, he or she may then perform a MiTM attack.
Replay attack
Captured packets could be replayed to the server by a malicious party, causing the server to call the original destination of a call. In other words, this would possibly take the form of a second unsolicited call request, identical to one the party had already received. Although a nuisance, the attacker themself would not be party of the call, as their IP information would not be included in the signalling packets.
Web servers are not stateful, with each request served a separate session (alleviates need for continuously authenticating). Cookies for authentication, but are nothing more than a data file containing the session ID. These cookies are sent by the web server to the browser upon initial access.
If the cookie were to be intercepted and copied, it could allow an interceptor full access to a session already in progress. In an attempt to mitigate this, most sites generate cookies using an algorithm involving user IP address and a timestamp to create a unique identifier.
Although it may seem that signalling provides a particularly tempting vantage-point for attackers to target, all is not lost. In addition to the media streams, the signalling layer can also be encrypted. One such encrypted option is OnSIP, which uses SIP over Secure WebSockets (wss:// instead of ws://), with the WebSocket connection encrypted by TLS.
Although outside of this report’s scope, other signalling technologies can similarly use TLS to encrypt their WebSocket or other web traffic. As with all encryption, if the third party does not know the secret encryption key, they are thereby unable to read the plain-text contents of the communication. This helps eliminate the risk of much of the above attack vectors, although it should be noted that the application programmer must specifically implement the encrypted signalling method for this to be applicable.
4.7. Additional Security Topics
Viewpoint of the Telecom Network
By providing support to WebRTC, a telecom network should resonably expect not be exposed to increased security risk. However, devices or software in the hands of consumers will inevitably be compromised by malicious parties.
For this reason, all data received from untrusted sources (e.g. from consumer/users) must be validated, and the telecom network must assume that any data sent to the client will be obtained by malicious souces.
By adopting these two principles, a telecom provider must strive to make all reasonable attempts at protecting the consumer from their own mistakes that may compromise their own systems.
Cross-site scripting (XSS)
Cross-site scripting is a type vulnerability typically found in web applications (such as web browsers through breaches of browser security) that enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy.
Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner.
As the primary method for accessing WebRTC is expected to be using HTML5 enabled browsers there are specific security considerations concerning their use such as; protecting keys and sensitive data from cross-site scripting or cross-domain attacks, websocket use, iframe security, and other issues. Because the client software will be controlled by the user and because the browser does not, in most cases, run in a protected environment there are additional chances that the WebRTC client will become compromised. This means all data sent to the client could be exposed.
5. Comparison with competing/similar technologies
An examination of WebRTC’s comparative security would fail to make sense without also considering the security of the competition. Fortunately for WebRTC, the competition in the web-based communication arena has its own share of issues.
This section will explore the comparitive strengths and weaknesses of WebRTC and other platforms offering competiting RTC functionality.
Some platforms we COULD explore are the following. The platforms to be explored have not yet been chosen. (To come after first-draft.)
Although widely relied upon, the additional installation processes can pose a barrier
6. Secure design practices
WebRTC is built to be secure. However more than just bindly relying on the underlying technology, it is a good idea to consciously code with security in mind. This section will discuss coding practices that may be followed to ensure greater security over a vanilla WebRTC implementation. In particular, these practices could be applicable to organisations which expect to handle senstive information, eg. banking institutions, healthcare institutions or confidential corporate information.
Secure Signalling
As mentioned previously, WebRTC does not impose any constraints on the signalling process, rather leaving the developer to decide upon their own preferred method. Although this allows for a degree of flexibility that can have the WebRTC implementation tailored to the needs of the application, there can be risks associated with certain signalling protocols.
It is advisable to implement a signalling protocol that provides additional security, such as encryption of signalling traffic. By default a signalling process may not incorporate any encryption, which can leave the contents of all exchanged signalling messages open to eavesdropping. Applications with a focus upon security/confidentiality should therefore ensure that their signalling layer is implemented over a secure protocol such as SIPS, OpenSIP, HTTPS or WSS.
Authentication and peer monitoring
A basic WebRTC app requires only a user’s ID in order to perform a call, with no authentication performed from the view point of the service itself. It may be desirable to require pre-registration or authentication before any user can participate in a call. Unauthenticated entities should then be kept away from session’s reach, restricting accessibility to untrusted parties.
Since the media connections are P2P, the media contents (audio and video channels) are transmitted between peers directly in full duplex. Thus as the signalling server maintains the number of peers in communication, it could be consistently monitored for addition of suspicious peers in a call session. If the number of peers actually present on signalling server is more that the number of peers interacting on WebRTC page then it could mean that someone is eavesdropping secretly and should be terminated from session access by force.
It is a noted behaviour that often users will agree to permission requests or similar dialogs without consciously reading the message. This poses the risk of granting a web application with permissions which were not actually intended by the user.
Although this behaviour itself can not be easily dealt with, one solution could be to clearly detail on the page what permissions the application will ask for. Such an application places a user’s privacy at the forefront.
In the eventuality that a malicious party succeeds in setting up a MitM attack, there is typically not an easy solution to discover or fight against it. This is because the attack has no warning, and communication is allowed to proceed as normal. If one is not expecting such an attack, the attack will likely continue unnoticed.
However, by monitoring the media path regularly for no suspicious relays, we can take one small step towards mitigating against MiTM attacks. This should be coupled with encrypted signalling, as mentioned above.
An application offering any degree of screen-sharing functionality should have warnings in place to protect the user. As previously discussed, a user may not be aware of the extent of the screen being shared. Such an issue should fall back to a properly designed application to provide appropriate such information.
For example, before initiating the streaming of any part of the screen, the user should be properly notified and advised to close any screen containing sensitive information.
A Fallback
As a final fallback measure, we could venture as far as imagining a situation in that an active call session is compromised by a unauthorised party. If a call is confirmed to be compromised in such a way, it should be within the power of Web Application server rendering the WebRTC capable page to cut off the call.
In the modern age of smartphones and mobile devices people are communicating more than ever, and in even more personal ways than we have known before. Encryption in particular has become a big topic in recent years, following the growing awareness of major corporate hacking scandels and widespread government telecommunication eavesdropping. The result of which has been a rapid increase in user distrust of such organisations, and calls for arms in implementing greatly improved security measures. All the end user wants is to know that their personal data is kept private under control.
WebRTC has a big advantage over most VoIP services in the security area. Until now, most services have typically treated security as optional, meaning most end users use VoIP calls without encryption. Large corporations in particular are a leading culprit for this, choosing to save money on cheaper implementations rather than properly considering their users or the value of the data that they handle. But as WebRTC forbids unencrypted communication, users can be assured that their data remains safe and private.
Having been designed with security in mind, WebRTC enforces or encourages important security concepts in all main area. As such, as well as simply being built secure, it encourages WebRTC developers to also take their security seriously.
As a result of this strong focus on secure communication, WebRTC is currently regarded by some to be one of the most secure VoIP solutions out there. The main premise of having encryption by default is that a call is private at all times. Security and encryption are no longer considered to be optional features. And to round everything off, WebRTC is available free to everyone, providing a tempting and reliable framework for developers to build their next application.
In the near future we can expect to see more and more communication services providing greatly increased security to their users. But for now, WebRTC is one of those who are leading the charge.
8. Bibliography
1. RTCPeerConnection API Reference.
developer.mozilla.org. Accessed on 2015-07-28.
2. Brief Introduction to RTCPeerConnection API.
High Performance Browser Networking. Accessed on 2015-07-28.
3. SDP for the WebRTC.
tools.ietf.org. Accessed on 2015-07-28.
4. After signaling: using ICE to cope with NATs and firewalls.
html5rocks.com. Accessed on 2015-07-28.
5. Getting Started with WebRTC – Security.
6. WebRTC Security – Same Origin Policy.
7. Security Considerations for WebRTC.
8. Attack of the week: Datagram TLS.
blog.cryptographyengineering.com. Accessed on 2015-07-28.
9. Web Real-Time Communication (WebRTC): Media Transport and Use of RTP.
10. The Foundation of WebRTC Security.
onsip.com. Accessed on 2015-07-28.
11. WebRTC MUST implement DTLS-SRTP but… MUST NOT implement SDES?.
webrtchacks.com. Accessed on 2015-07-28.
12. IETF-87 rtcweb agenda.
13. Security Considerations for WebRTC.
www.ietf.org. Accessed on 2015-07-28.
14. WebRTC and Man in the Middle Attacks.
15. Security in a SIP network: Identifying network attacks.
searchunifiedcommunications.techtarget.com. Accessed on 2015-07-28.
16. Two attacks against VoIP.
symantec.com. Accessed on 2015-07-28.
17. Security for WebRTC applications.
altanaitelecom.wordpress.com. Accessed on 2015-07-28.
18. WebRTC Security.
19. Why WebRTC is the Most Secure VoIP Solution.
bloggeek.me. Accessed on 2015-07-28.
A Study of WebRTC Security is a NTT Communications project.
builtjobPortalrequirement转自
程序员艳庆
上一篇： RTP RTCP在音视频传输与同步方面的使用
下一篇： Spring之ResourceLoader加载资源


Relatively Painless Games - Week 2: The Ever-Looming Words "Sprint Fail"
First off, the most important thing that we decided on during this week was that we were going to drop Thievery. We brought the idea to our class and we quickly learned through feedback just how out of scope Thievery was.
The idea of the game was a competitive stealth game in which the players tried to steal more than the other players while trying to alert the guards of each others' position through things like Smoke Bombs, Tripwires, and other distractions. The main problem that came up was that it is hard to have a stealth game where the players interact meaningfully and often with each other. From a design standpoint, this left the idea of the game in a state where it was very, very, very hit or miss. And we felt that the these problems plus the scope from both an environmental art standpoint and AI programming standpoint made this game undesirable in terms of viability within scope.
Then we made a further mistake.
So, we decided part way through that we were dropping Thievery. But, the tasks and story of it were already in our Sprint. We were far too afraid of two looming words - "Sprint Fail." Because of that, we worked on a Thievery prototype despite the fact that we were going to drop it when we could have instead replaced that prototype with something that would have likely been more useful.
This did frustrate me in particular because I had decided to take on this prototype, and I felt like I was creating something that was pretty pointless. But, rather than stay frustrated, I tried to figure out what we could do with the prototype to make it useful. And so, I ended up making it so that the different abilities and items the player had had multiple functions. For example, I made it so that the tripwire costed treasure (the points within the game) to make it so that the treasure had multiple purposes: adding up to your final points or possibly causing another player to lose points. I also made it so that the Smoke Bomb made it so guards couldn't walk through it, however guards would still be attracted to the smoke bomb, making it so that you could use it defensively for yourself or on opponents to attract guards to their location. I did this to get some feedback on items with multiple uses, which could be useful in both of our other game ideas. For the game where you take the remains of robots and attach them to yourself to augment yourself, some of the items the player picks up could have multiple uses. For the game where monsters fuse together upon death, the player can have abilities with multiple uses rather than just the usual combat system.
Of course, though, by the end of the Sprint we realized we shouldn't have been as afraid of Sprint Fail. We learned that while 100% finishing the Sprint may be the goal, not doing so isn't truly a failure. Plans change throughout a Sprint. That's the whole point of Agile Scrum Development and these Sprints and Milestones.


Five Takeaways from President Trump’s First State of the Union Address
Shane Vander Hart offers his five quick takeaways from President Donald Trump’s first State of the Union address outlining his first year in office and his vision for 2018.
CBS Poll Shows 75 Percent of Viewers Approve of Trump’s SOTU Address
economic policy,
immigration,
MS-13,
North Korea,
I wanted to offer some thoughts about President Donald Trump’s first State of the Union Address tonight. Here are five quick takeaways from the speech (not meant to be exhaustive).
1. The stories were great.
When Presidents talk about their guests at the State of the Union it is an opportunity for some powerful moments. President Trump’s speech was no exception.
I loved the pro-life example given of Ryan and Rebecca Holet who adopted the baby of a homeless heroin addict.
They named her Hope, and yes they are an example of what makes our nation good. I appreciated the story.
My heart broke for the parents of Kayla Cuevas and Nisa Mickens who were murdered by members of MS-13, as well as, the parents of Otto Warmbier who was sentenced to 15-years in North Korea to be later released shortly before his death.
Ji Seong-ho, who bravely fled North Korea, holding his crutches over his head was a powerful image.
I could go on because there were other stories as well. This, bar none, was the best part of his speech.
2. The economy speaks for itself.
The strongest case that President Trump can make for his administration was economic growth. In particular:
Since the election, we have created 2.4 million new jobs, including 200,000 new jobs in manufacturing alone. After years of wage stagnation, we are finally seeing rising wages.
Unemployment claims have hit a 45-year low. African-American unemployment stands at the lowest rate ever recorded, and Hispanic American unemployment has also reached the lowest levels in history.
Then comes the tax cuts which outside of the confirmation of Neil Gorsuch to the Supreme Court was probably the greatest achievement in his first year in office.
He highlighted how it is stimulating the economy:
Small businesses have also received a massive tax cut, and can now deduct 20 percent of their business income.
Here tonight are Steve Staub and Sandy Keplinger of Staub Manufacturing — a small business in Ohio. They have just finished the best year in their 20-year history. Because of tax reform, they are handing out raises, hiring an additional 14 people, and expanding into the building next door.
One of Staub’s employees, Corey Adams, is also with us tonight. Corey is an all-American worker. He supported himself through high school, lost his job during the 2008 recession, and was later hired by Staub, where he trained to become a welder. Like many hardworking Americans, Corey plans to invest his tax‑cut raise into his new home and his two daughters’ education. Please join me in congratulating Corey.
Since we passed tax cuts, roughly 3 million workers have already gotten tax cut bonuses — many of them thousands of dollars per worker. Apple has just announced it plans to invest a total of $350 billion in America, and hire another 20,000 workers.
3. His immigration plan will make both the far right and far left angry.
In terms of policy, this is where he provided the most meat.
The first pillar of our framework generously offers a path to citizenship for 1.8 million illegal immigrants who were brought here by their parents at a young age — that covers almost three times more people than the previous administration. Under our plan, those who meet education and work requirements, and show good moral character, will be able to become full citizens of the United States.
The second pillar fully secures the border. That means building a wall on the Southern border, and it means hiring more heroes like CJ to keep our communities safe. Crucially, our plan closes the terrible loopholes exploited by criminals and terrorists to enter our country — and it finally ends the dangerous practice of “catch and release.”
The third pillar ends the visa lottery — a program that randomly hands out green cards without any regard for skill, merit, or the safety of our people. It is time to begin moving towards a merit-based immigration system — one that admits people who are skilled, who want to work, who will contribute to our society, and who will love and respect our country.
The fourth and final pillar protects the nuclear family by ending chain migration. Under the current broken system, a single immigrant can bring in virtually unlimited numbers of distant relatives. Under our plan, we focus on the immediate family by limiting sponsorships to spouses and minor children. This vital reform is necessary, not just for our economy, but for our security, and our future.
The far right will not like offering DACA recipients a pathway to citizenship. The far left (or should I just say the Democratic Party) will be unhappy with the rest. This is going to be a big lift and I’m doubtful Congress will pass this.
4. The optics of Democrats’ staying seated when they shouldn’t.
I am not sure if Democrats think they are making inroads with average Americans by not applauding historically low unemployment claims, tax cuts, and corporate investment at home, but they are not. This mindset is exactly why they lost in 2016.
One of the most entertaining aspects of the State of the Union was watching House Minority Leader Nancy Pelosi (D-CA) throughout the speech when they would flash at her.
Democrats need to find a different game plan other than “we hate Trump.”
5. It was policy-lite.
With the exception of the immigration, his speech lacked a lot of detail.
He’s planning on spending a lot of money on infrastructure, but I’m still unclear what his plan will look like. He’s changing the rules of engagement in Afghanistan, but what does that mean? He doesn’t want to repeat the mistakes made by other Presidents with North Korea, so what will he do differently?
Somethings like his plan for keeping Guantanamo open and ending the catch and release program for terrorists is pretty clear.
I was half expecting that he was going to call for Congress to declare war on MS-13, way, way, way too much time spent on that.
Overall it was a good speech, probably too long, but good. I don’t know if it will move the needle for him, speeches rarely do, but if he can stay off Twitter and give speeches like this it will go a long way.
McCain-Led NDAA Conference Committee Strips Right to Jury Trial
Senator Rand Paul (R-KY) criticizes the NDAA Conference Committee led by Senator John McCain (R-AZ) whose report strips the right to trial by jury.
Relief for Americans Caught in the Obamacare Tax Penalty Catch-22
David Young: It is simply wrong to take money out of the pockets of hardworking Iowans who live in those health care desert counties as a penalty for not having insurance.
The Obama Justice Department Takes Another Stand for Voter Fraud
If you are a science fiction fan you know that a popular…
A Renewed Call for a Federal Marriage Amendment
The solution to the marriage issue is to adopt a federal marriage amendment which protects traditional marriage.
John Hendrickson